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%  The  purpose  of  this  study  was  to  investigate  a  methodology 
for  the  ongoing  analysis  and  design  of  a  decision  support 
system  (DSS)  for  retasking  decisions  made  by  the  fighter  duty 
officer  (FDO)  in- the  -Air  Support  Operations  Center  (ASOC).-\An 
adaptive  design  approach  was  chosen  and  modified  to  minimise  the 
problems  of  miscommunication  and  prespeciftfcation  that 
traditional  analysis  and  design  presents.  -^The  research  had  five 
main  objectives:  (1)  Determine  through  concept  mapping  and 
discussions  with  FDOs  from  the  ASOC,  the  decision  processes  that 
he  would  make  during  retasking  of  Close  Air  Support  (CAS)  and 
Battlefield  Air  Interdiction  (BAI)  missions.  (2)  Establish  a 
central  decision  process  ("kernel”)  that  would  benefit  from  a 
DSS.  (3)  Translate  the  initial  requirements  established  through 
this  analysis  into  a  set  of  screen  representations  ("storyboard") 
that  the  FDO  can  use  as  an  initial  retasking  DSS.  (4)  Evaluate 
the  effectiveness  of  the  adaptive  design  methodology  for 
determining  initial  requirements j  and  the  ability  of  the 
storyboard  to  serve  -as  a  dynamic;  statement  of  requirements  as 
the  DSS  grows. -fifS)  Investigate  details  of  the  adaptive  design 
approach  within  this  application  that  facilitate  or  hinder  the 
methodology. 

This  resteetrch  produced  a  kernel  storyboard  through  the 
iterative  cycles  of  the  design  process.  This  design  was  then 
analytically  evaluated  using  measures  of  effectiveness  such  as: 

(1)  proper  assignment  of  functions,  (2)  structural  complexity, 
and  (3)  compatibility  and  understandability .  This  research 
demonstrated  that  segmentation  of  the  complex  re tasking  problem 
into  kernels  provides  a  plan  for  gradual,  managable  growth  of 
the  DSS.  Problems  of  miscommunication  and  attempting  to  prespecify 
all  the  users  needs  at  the  start  were  avoided  with  the  adaptive 
approach.  Additionally,  it  was  verified  that  adaptive  design 
requires  a  plan  and  strong  organizational  support  to  be  effective. 
Recommendations  for  continuing  the  adaptive  design  and  implementing 
the  operational  retasking  prototype  are  also  addressed  in  this 
thesis . 
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Preface 


The  purpose  of  this  thesis  was  to  investigate  how  we  can  best  apply 
adaptive  design  to  build  a  decision  support  system  (DSS)  to  meet  the  current 
Air  Force  needs  in  the  Air  Support  Operations  Center  (ASOC).  The  emphasis 
throughout  this  study  has  been  on  how  we  can  better  integrate  the  ASOC 
_  Jsionmaker  in  the  iterative  design  process  throughout  the  life  of  the  DSS. 

The  methods  I  propose  for  successful  adaptive  design  of  the  ASOC  DSS 
require  radically  different  thinking.  Perhaps  the  biggest  difference  between 
adaptive  design  and  our  traditional  system  design  methods  lies  in  the  role  of 
the  user;  adaptive  design  requires  continual  input  from  the  user  as  his 
perceptions  of  the  problem  and  his  needs  change. 

Much  of  the  inspiration  for  this  work  came  from  my  thesis  advisor,  Lt 
Colonel  "Skip"  Valusek.  His  guidance  and  support  throughout  the  project 
were  a  great  source  of  strength.  I  would  also  like  to  thank  the 
decisionmakers  at  the  682  ASOC,  Shaw  AFB,  especially  Captain  John  Meroth, 
who  provided  valuable  input  during  the  early  design  phase.  Lt  Colonel 
Kozma,  and  his  staff  at  TAC/DOYF  deserve  thanks  for  the  advice  they 
provided;  I  look  forward  to  working  with  them  on  tactical  system 
requirements.  I  also  wish  to  acknowledge  Mr.  Mike  Young,  Major  Duard 
Woffinden,  and  Captain  Mark  Roth  for  their  time  and  helpful  criticism 
during  the  project. 

Lastly,  I  wish  to  thank  family  and  friends  who  have  supported  me  with 
prayers  throughout  this  challenging  thesis  project. 
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Abstract 


The  purpose  of  this  study  was  to  investigate  a  methodology  for  the 
ongoing  analysis  and  design  of  a  decision  support  system  (DSS)  for  retasking 
decisions  made  by  the  fighter  duty  officer  (FDO)  in  the  Air  Support 
Operations  Center  (ASOC).  An  adaptive  design  approach  was  chosen  and 
modified  to  minimize  the  problems  of  miscommunication  and 
prespecification  that  traditional  analysis  and  design  presents.  The  research 
had  five  main  objectives:  (1)  Determine  through  concept  mapping  and 
discussions  with  FDOs  from  the  ASOC,  the  decision  processes  that  the  FDO 
would  make  during  retasking  of  missions.  (2)  Establish  a  central  decision 
process  ("kernel")  from  the  ASOC  that  would  benefit  from  a  DSS.  (3) 
Translate  the  initial  requirements  established  through  this  analysis  into  a  set 
of  screen  representations  ("storyboard")  that  the  FDO  can  use  as  an  initial 
retasking  DSS.  (4)  Evaluate  the  effectiveness  of  the  adaptive  design 
methodology  for  determining  initial  requirements,  and  the  ability  of  the 
techniques  to  serve  as  a  dynamic  statement  of  requirements  as  the  DSS 
grows.  (5)  Investigate  details  of  the  adaptive  design  approach  within  this 
application  that  facilitate  or  hinder  the  methodology. 

This  research  produced  a  kernel  storyboard  through  the  iterative  cycles 
of  the  design  process.  This  design  was  then  analytically  evaluated  using 
measures  of  effectiveness  such  as:  (1)  proper  assignment  of  functions,  (2) 
structural  complexity,  and  (3)  compatibility  and  understandability.  The 
Macintosh™  software  HyperCard™  was  used  as  a  tool  to  assemble  a 
"part-task  simulator"  for  the  DSS.  The  graphical  display  and  linking 
capabilities  of  this  software  proved  useful  for  design  enhancement. 

Overall,  the  research  demonstrated  that  using  an  adaptive  approach  to 


the  retasking  DSS  design  provides  a  "communication  anchor  to  enable  and 
enhance  dialogue"  between  decisionmaker  and  designer.  It  was  also  found 
that  segmentation  of  the  complex  retasking  problem  into  kernels  provides  a 
plan  for  gradual,  managable  growth  of  the  DSS.  Problems  of 
miscommunication  and  attempting  to  prespecify  all  the  users  needs  at  the 
start  were  avoided  with  the  adaptive  approach.  Additionally,  it  was  verified 
that  adaptive  design  requires  a  plan  and  strong  organizational  support  to  be 
effective. 

Recommendations  for  continuing  the  adaptive  design  and  implementing 
the  operational  retasking  prototype  are  also  addressed  in  this  study. 


ADAPTIVE  DESIGN  OF 
A  DECISION  SUPPORT  SYSTEM 
FOR  DYNAMIC  RETASKING  OF 
CAS  AND  BAI  ASSETS 

I.  Introduction 

Formulating  the  Problem 

Through  recent  academic  study  of  system  design  techniques,  this 
researcher  has  become  interested  in  the  unique  challenges  that  await  the 
designers  and  builders  of  decision  support  systems  (DSS).  With  an  interest 
in  further  investigating  this  relatively  new  multidisciplinary  approach  to 
command  and  control  (C2)  problems,  this  researcher  began  a  search  for  a 
suitable  military  application  area.  One  specific  area  that  was  suggested 
earlier  this  year  by  engineers  in  the  Rome  Air  Development  Center  Decision 
Aids  Branch  is  the  need  for  further  study  and  work  centering  around  the  Air 
Support  Operations  Center  (ASOC)  mission  and  responsibilities. 

Basically,  the  ASOC  is  responsible  for  execution  of  close  air  support  (CAS) 
and  planning  of  battlefield  air  interdiction  (BAI)  missions  in  support  of  the 
Army.  In  this  role,  the  ASOC  is  not  well  prepared  to  execute  and  plan 
flexibly.  When  it  comes  to  being  able  to  rapidly  replan  missions,  and  to 
quickly  examine  the  feasibility  of  retasking  or  diverting  missions,  the  ASOC 
has  many  deficiencies.  Part  of  the  reason  for  these  deficiencies  is  that 
mission  executers  in  the  ASOC  have  not  traditionally  envisioned  the  activity 
of  retasking,  or  the  recommendation  to  retask,  as  part  of  their  formal 


responsibility.  Perhaps  the  larger  problem  though,  is  the  absence  of  a 
support  system  to  assist  the  decisionmaker  with  the  retasking  decisions. 

Given  these  recognized  deficiencies,  the  ASOC  appears  to  be  a  ripe  area  for 
investigating  the  utility  and  possible  design  of  a  retasking  DSS.  This 
application  area  also  appears  suitable  because  of  the  limited  scope  of  the 
tactical  ASOC  environment,  coupled  with  the  apparent  applicability  of  an 
evolutionary  or  adaptive  approach  to  the  design  work  that  needs  to  be 
accomplished.  The  remainder  of  this  chapter  discusses  several  aspects  of  the 
tactical  environment  relevant  to  the  ASOC,  and  finally,  focuses  on  the 
deficiencies  in  the  ASOC  that  will  be  addressed  by  a  retasking  DSS. 

The  Overall  Tactical  Challenge 

Technology  is  one  of  the  major  forces  influencing  the  progression  of 
military  operations  and  the  systems  that  support  those  operations.  Today’s 
current  tactical  fighters  offer  increased  capability  for  initiative  against  the 
enemy  in  a  joint  scenario.  At  the  same  time  modem  enemy  defenses  pose 
new  threats  for  both  friendly  land  and  air  assets.  As  another  example, 
sophisticated  ground  threats  such  as  surface-to-air  missiles  (SAMs)  pose 
lethal  threats  for  aircraft  on  CAS  and  BAI  missions.  In  other  high  technology 
areas,  the  current  state-of-the-art  communication  and  computer  systems  are 
designed  to  be  less  vulnerable  to  enemy  interception  and  countermeasures. 
These  communication  and  computer  systems  are  able  to  capture,  process, 
and  transmit  substantial  amounts  of  information  about  the  enemy,  and  thus 
can  provide  much  of  the  enemy  and  friendly  force  status  to  battle  managers 
on  a  near-real-time  basis.  This  information  is  most  useful  to  the  joint  tactical 
planners  and  mission  executors  if  they  realize  its  significance  to  those 
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portions  of  the  tactical  environment  they  manage.  They  can  then  include 
this  information  in  their  decisionmaking  and  joint  planning.  A  more 
thorough  integration  of  the  available  battlefield  information  with  the 
decisionmaking  of  the  command  and  control  cycle  is  needed. 

The  way  that  this  decisionmaking  information  is  used  may  well  influence 
the  success  of  integrating  joint  military  capabilities  and  forces  in  a  concerted 
effort,  and  may  ultimately  affect  the  outcome  of  the  conflict.  If  they  are 
planned  and  executed  successfully,  the  combined  effect  of  joint  operations  is 
to  wield  a  greater  impact  where  and  when  it  is  needed  on  the  battlefield; 
greater  than  if  each  of  the  forces  were  operating  independently.  However, 
the  joint  tactical  battle  is  becoming  exceedingly  difficult  to  plan  for  and  then 
flexibly  execute.  Although  the  technology  exists,  and  the  decisionmaking 
information  can  be  gathered,  the  systems  needed  to  command  and  control 
the  joint  forces  are  not  all  developed  or  in  place.  Many  of  these  support 
systems  are  still  in  their  early  conceptual  and  design  phases.  The 
operational  experts  in  concert  with  the  system  designers  and  builders  have 
not  been  able  to  develop  the  command  and  control  decision  support  systems 
to  keep  pace  with  recent  technological  advances.  Often,  it  seems  that 
technology  provides  the  impetus  for  redefining  and  refining  system 
requirements;  this  technology  and  the  information  it  provides  to 
decisionmakers  is  heavily  influencing  the  demand  and  justification  for 
today's  decision  support  systems. 

The  bottom  line  is  this:  if  our  tactical  military  forces  are  to  capitalize  on 
the  benefits  of  modem  technology,  and  use  it  to  our  advantage  in  tactical 
battle,  they  must  possess  systems  to  support  their  command  and  control 
decisions. 
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Command  and  Control 

A  general,  all-encompassing  definition  for  command  and  control  is  the 
approved  Department  of  Defense  (DOD)  definition  found  in  Joint  Chiefs  of 
Staff  (JCS)  Pub  1: 

The  exercise  of  authority  and  direction  by  a  properly 
designated  commander  over  assigned  forces  in  the 
accomplishment  of  his  mission.  Command  and  control 
functions  are  performed  through  an  arrangement  of 
personnel,  equipment,  communications,  facilities,  and 
procedures  which  are  employed  by  a  commander  in 
planning,  directing,  coordinating  and  controlling  forces  and 
operations  in  the  accomplishment  of  his  mission. 


One  of  the  keys  to  effective  command  and  control  at  all  levels  of  future 
tactical  battles  will  be  the  smart  joint  integration  of  personnel,  equipment, 
communications,  facilities,  and  procedures  to  accomplish  the  commander's 
objectives.  Although  this  definition  covers  the  activities  of  command  and 
control  adequately,  it  misses  a  key  point  that  the  next  definition 
emphasizes. 

This  alternate  definition,  that  focuses  on  the  decisionmaking  aspects  of 
command  and  control,  is  offered: 


...  a  process:  or  more  accurately,  a  set  of  related 
processes.  It  is,  first,  a  process  of  getting  information  to 
decisionmakers.  Second,  it  is  a  process  of  interaction  between 
decision  makers.  Third,  it  is  a  process  of  implementing  their 
decisions.  All  three  of  these  vital  processes  are  centered  around 
decisionmakers:  the  task  of  command  and  control  is  to  help  them 
see  more  clearly  what  is  happening,  decide  what  to  do  about  it  and 
implement  the  necessary  actions  (Conwell,  1984  :  13). 
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This  definition  of  C  focuses  on  the  most  critical  and  toughest  part  of  the 
process:  decisionmaking.  It  also  more  closely  matches  the  conceptual  process 
model  for  C  developed  by  the  Military  Operations  Research  Society  (MORS). 
This  process  model  includes  the  activities  of  sensing  stimuli,  assessing  data, 
generating  options,  selecting  alternative,  and  planning  and  directing  a 
response  (Sweet  and  others,  1985  :  Ch  5,  4).  These  two  latter  definitions 
establish  a  better  frame  of  reference  for  C  and  the  possible  role  of  a  DSS  in 
this  process. 
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With  this  C  frame  of  reference,  several  initiatives  within  the  Army  and 
Air  Force  to  improve  the  C  process  are  discussed  below.  The  Army  and  Air 
Force  initiatives  are  of  particular  interest  because  these  two  services  provide 
decisionmakers  for  the  tactical  decision  making  within  the  ASOC. 

US  Army  Initiatives 

The  US  Army  is  actively  incorporating  the  latest  technology  into  their 
current  operational  concept,  or  Airland  Battle  doctrine.  This  doctrine 
essentially  requires  commanders  "to  attack  the  enemy  through  the  depth  of 
his  formations,  bring  about  and  accept  close  combat  on  favorable  terrain 
with  acceptable  combat  power  ratios,  and  employ  reserves  at  the  decisive 
(optimal)  time  to  complete  the  destruction  of  the  enemy"  (McKinney, 1984). 

A  former  commander  of  the  US  Army  Training  and  Doctrine  Command 
clarifies  this  point: 

Airland  Battle  ...  states  that  the  battle  against  the  second 
echelon  forces  is  equal  in  importance  to  the  fight  with  the 
forces  at  the  front.  Thus  the  traditional  concern  of  the 
ground  commander  with  the  close-in  fight  at  the  forward 
line  of  own  troops  (FLOT)  is  now  inseparable  from  the  deep 


attack  against  the  follow-on  forces.  To  be  able  to  fight 
these  simultaneous  battles,  all  of  the  armed  services  must 
work  in  close  cooperation  and  harmony  with  each  other.  If 
we  are  to  find,  to  delay,  to  disrupt  and  to  kill  the  total 
enemy  force,  we  will  need  the  combined  efforts  of  the 
Air-Army  team"  (General  Glenn  K.  Otis) 

This  statement  affirms  both  the  inseparability  of  the  CAS  missions  and 
second  echelon,  or  BAI  missions,  as  well  as  the  necessity  for  the  Army  and 
Air  Force  to  accomplish  these  missions  in  a  combined  and  closely  coordinated 
fashion. 

The  Army  describes  their  plan  for  accomplishing  these  goals  on  the 
future  battlefield  in  their  Army  21  doctrine;  a  plan  which  "depends  largely 
on  high  mobility,  deep  strike  and  surgical  interdiction  strategies"  (CJI 
Management,  1986).  According  to  Dr.  Mark  Epstein,  Deputy  Chief  for  C  l  in 
the  Office  of  the  Assistant  Secretary  of  the  Army,  "we've  modernized  our 
weaponry  substantially  over  the  last  five,  six  seven  years  . . .  and  during  that 
period  we  did  not  modernize  the  C^I  unit "  (C^I  Management,  1986).  He 
further  states  what  is  needed  is  a  more  thorough  integration  of  command, 
control  and  information  elements  including  a  variety  of  sensors, 
communications  links,  C4,  support  facilities  as  well  as  information  processing 
and  display  equipment  with  weapons. 

Some  of  the  most  critical  new  programs  that  the  Army  is  developing  with 

'J 

the  Air  Force  and  Navy  to  support  these  C  l  deficiencies  are  the  Milstar 
satellite  communications  system.  Joint  Tactical  Information  Distribution 
System  (JTIDS),  Joint  Surveillance  Target  Attack  Radar  System  (J STARS), 
and  the  Joint  Tactical  Fusion  program  including  the  All  Source  Analysis 
System  (ASAS).  The  ASAS  is  a  good  example  of  a  system  that  integrates 
information  with  the  C  decision  process;  essentially,  ASAS  will  "identify 


time-critical  tactical  intelligence  inputs  and  generate  predictions  on  enemy 
battle  strategy  based  on  new  data  and  known  methods  of  operation"  (C^I 
Management,  1986).  Careful  joint  integration  of  these  and  a  host  of  other 
C^I  initiatives  with  the  other  military  services  will  allow  the  Army  to  meet 
the  goals  of  their  Army  21  doctrine. 

Within  the  joint  tactical  Airland  Battle  environment,  the  Air  Force 
Tactical  Air  Control  System  (TACS)  provides  the  centralized  planning  and 
decentralized  execution  of  the  air  battle,  in  support  of  the  joint  commander’s 
objectives.  Each  of  the  different  theaters  have  devised  their  own  slightly 
different  systems  based  on  this  general  TACS  concept.  Specifically,  the 
Tactical  Air  Control  Center  (TACC)  acts  as  the  operational  center  of  command 
and  control  for  the  Air  Component  Commander  (ACC).  In  the  NATO 
environment,  the  equivalent  of  the  TACC  is  the  Air  Tactical  Operations 
Center  (ATOC).  The  role  of  the  ATOC  in  planning  and  execution  is  almost 
identical  to  a  TACC  that  deploys  from  the  US,  so  no  distinction  will  be  made 
between  these  two  tactical  agencies. 

Below  the  TACC  is  the  Air  Support  Operations  Center  (ASOC),  which  is  the 
arm  of  the  TACS  that  receives  and  coordinates  air  requests  in  support  of  the 
Army  ground  forces  (see  Figure  1,  Proposed  Upgraded  ASOC  System).  The 
ASOC  is  generally  collocated  with  the  corps  staff  at  the  Corps  Tactical 
Operations  Center  (CTOC),  but  may  also  be  employed  at  field  Army  level  or 
with  an  independent  operating  division  or  brigade.  The  ASOC  is  concerned 
primarily  with  the  exchange  of  combat  data  between  air  and  ground  forces 
and  the  coordination  and  execution  of  close  air  support  (CAS)  of  ground  units 
and  planning  for  Battlefield  Air  Interdiction  (BAI)  missions  with  the  Army. 
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In  these  roles,  the  ASOC  is  the  arm  of  the  TACS  that  needs  to  be  most 
closely  aligned  and  synchronized  with  the  current  Army  operation.  In  an 
Airland  battle  that  begins  at  the  FLOT,  extends  to  the  second  echelon  and 
may  include  surgical  interdiction  and  special  operations  in-between,  the 
requirement  for  an  effective  Air  Force  liaison  at  Corp  level  is  critical.  The 
ASOC  basically  functions  in  this  liaison  role  by  providing  expert  advice  on  air 
assets  and  capabilities,  and  coordinating  the  integrated  plan  between  the 
Army  initiatives  and  Air  Force  close-air  and  battlefield  interdiction  support. 

Air  Force  Initiatives 

Two  complimentary  Air  Force  TACS  programs  have  been  spearheaded  in 
the  last  year  to  enhance  the  command  and  control  capabilities  of  the  air 
component  commander  and  increase  the  integration  and  interoperability 
during  joint  operations.  The  Tacpcal  Battle  Management  (TBM)  program 
provides  a  general  framework  for  the  two  by  recommending  an  evolutionary 
or  gradual-growth  approach  to  developing  and  acquiring  enhanced  C^I 
systems  to  support  contingency  TACS  planning  and  execution.  At  the  TACC 
level,  the  goal  of  TBM  is  to  integrate  a  number  of  existing  and  planned 
automated  systems  and  decision  aids.  This  integration  would  naturally  filter 
down  to  the  ASOC  level  as  well. 

The  other  Air  Force  initiative  still  in  its  conceptual  phase  is  the 
Contingency  TACS  Automated  Planning  System  (CTAPS).  This  project  is 
aimed  at  providing  an  Ops-Intel  integrated  C^  system  to:  ( 1 )  improve 
operational  plans  development  time,  (2)  provide  theater  to  theater 
interoperability  and  (3)  improve  command  level  and  execution  level 
communications.  This  program  is  like  TBM  in  that  an  evolutionary  approach 
is  planned  to  field  an  operational  system  as  quickly  as  possible  using 


off-the-shelf  hardware  and  software  that  exists  or  is  currently  being 
developed. 

Evolutionary  Approach 

Both  of  these  programs  are  of  particular  interest  to  this  researcher 
because  they  are  planned  to  be  evolutionary  or  adaptive  in  nature. 
Specifically,  in  this  case,  this  translates  into  a  development  approach  that 
will  employ  complimentary  user/developer  test  facilities  at  Langley  AFBV  VA 
and  Hanscom  AFB,  MA.  These  facilities  will  be  interconnected  to  share  the 
development  effort  and  exchange  information.  Many  software  modules  will 
be  modified  from  existing  software  and  plugged-into  the  larger  system 
under  development.  A  baseline  capability  is  planned  from  the  beginning 
and  releases/versions  of  the  system  will  be  built  incrementally,  and  quickly 
fielded  for  user  testing.  Strong  user  involvement  in  testing  and  evaluation 
throughout  the  program  will  be  emphasized. 

From  this  short  description  one  can  guess  that  the  innovative  and 
dynamic  management  of  the  programs  is  likely  to  field  successful  systems 
within  a  mininum  of  time,  if  we  disregard  the  technical  problems  or  political 
roadblocks  that  may  arise  during  the  programs.  These  evolutionary 
programs  present  many  opportunities  for  further  research  and  study  if  an 
effective  C^I  system  is  to  be  fielded  at  all  levels  of  the  TACS.  The 
evolutionary  approach  that  TAC  is  promoting  for  these  major  programs 
meshes  nicely  with  an  adaptive  approach  to  designing  the  ASOC  DSS  that  is 
being  studied  here.  As  will  be  discussed  later,  adaptive  design  also  includes 
methods  for  the  user  to  generate  and  refine  system  requirements  as  the  DSS 
evolves;  adaptive  design  addresses  many  of  the  front  end  activities  of 
system  design  that  have  traditionally  been  neglected. 
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Current  ASUl  Organization  and  Responsibilities 

The  ASOC  is  commanded  by  a  director  and  a  senior  operations  officer. 
Functional  positions  within  ASOC  operations  normally  include:  the  fighter 
duty  officer  (FDO),  reconnaissance  duty  officer  (RDO),  tactical  air  command 
and  control  specialists,  air  intelligence  and  targets  officers,  intelligence 
technicians,  and  information  systems  operators  (radio  operators)  (TACR 
55-46, 1986  :  Ch  2, 1). 

The  ASOC  fills  Army  requirements  for  immediate  tactical  air  support 
from  allocated  sorties  or  by  authorized  diversion  of  preplanned  sorties.  The 
ASOC  keeps  the  TACC  advised  of  the  air  effort  needed  to  satisfy  Army 
tactical  air  support  requirements  and  will  request  additional  tactical  air 
resources  when  requirements  exceed  the  sortie  allocation.  Essentially,  the 
ASOC  Director  must  insure  that  air  assets  are  used  in  the  most  effective 
manner  commensurate  with  the  current  threat,  the  battlefield  situation  and 
the  disposition  of  friendly  air  defense  weapons. 

The  system  that  exists  today  to  accomplish  these  ASOC  missions  dates 
back  to  the  1 960s.  Automated  systems  are  non-existent  in  the  ASOC,  with 
the  exception  of  the  current  plan  to  provide  them  with  one  Computer 
Assisted  Force  Management  System  (CAFMS)  terminal.  This  terminal  will  be 
used  to  receive  their  portion  of  the  daily  Air  Tasking  Order  (ATO)  and 
provide  a  communications  link  to  the  operational  flying  units  for  scrambling 
sorties  and  reviewing  current  status  of  aircraft  assets. 

Some  of  the  deficiencies  in  the  ASOC  are  outlined  in  the  recently 
published  Statement  of  Operational  Need  (SON)  for  ASOC  Improvements. 
Although  the  document  does  not  explicitly  state  the  need  for  retasking  in  the 
ASOC,  it  does  make  provision  for  the  development  of  a  future  ASOC  in  the 
long  term  (10  years).  Through  conversations  with  experts  and  planners  at 
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various  levels,  it  is  widely  accepted  that  the  requirement  to  rapidly  retask 
and  divert  exists.  In  addition,  much  of  the  hardware  system  requirements 
that  are  outlined  in  the  SON  suggest  that  this  is  what  the  planners  have  in 
mind  for  the  long  term  plan,  but  are  more  interested  in  fixing  the  gaping 
planning  deficiencies  at  this  time.  Specifically,  the  SON  states  that  "the 
current  ASOC  is  operationally  deficient  in  the  areas  of  mission 
requirements/request  processing,  resource  status  reporting,  mission 
schedule  monitoring,  mission  results  and  special  events  reporting.”  It 
further  states  that  "as  all  types  of  operational  message  traffic  increase,  the 
ASOC  operational  mission  data  becomes  less  current  because  of  workload  in 
manual  processing,  dissemination,  transmitting  and  posting  of  information. 
As  a  result,  operational  missions  may  not  be  alerted,  scrambled,  or 
diverted  within  acceptable  time  limits"  (TAF  SON _ -87,  1987:  2). 

Perhaps  another  deficiency  just  as  significant  as  these  is  the  absence  of 
any  mechanism  (automated  or  manual)  in  the  ASOC  to  assist  the  personnel  in 
integrating  their  efforts  with  the  Army's  airland  battle  initiatives.  Both  the 
battle  at  the  FLOT  and  that  at  the  second  echelon  are  expected  to  be 
changing  rapidly  in  future  conflicts.  Priorities  on  Army  targets  will  be 
shifting,  target  locations  and  accessibility  will  be  changing,  and  new 
unanticipated  targets  will  require  immediate  attention  and  rapid  planning. 

The  Air  Force  FDO  in  the  ASOC  will  be  required  to  work  closely  with  the 
Army  Operations  Officer  (G-3)  to  respond  to  this  changing  environment.  The 
Army's  integration  of  targets  on  the  FLOT  and  second  echelon  will  have  to  be 
understood  and  situationally  displayed  for  the  FDO  in  the  ASOC,  in  order  for 
him  to  optimally  respond  to  the  Army's  needs  for  air  support. 

It  is  envisioned  by  this  researcher  that  there  will  be  a  recurring  need  to 
retask  missions  as  the  battle  priorities  and  targets  dynamically  change. 


W’thin  the  scenarios  discussed  above,  there  will  be  a  greater  need  than  in 
the  past,  to  use  the  most  effective  weapon  against  each  target.  There  also 
exists  the  potential  for  a  greater  variety  of  targets  and  the  possibility  of 
unanticipated  targets  immediately  rising  to  the  top  of  the  Army's  priority 
target  list. 

Some  of  these  same  issues  and  questions  were  addressed  in  a  recent  AFIT 
thesis  by  Schoeck.  Although  he  focused  on  Air  Interdiction  (AI)  assets,  he 
proposed  that  "the  ability  to  make  rapid  decisions  with  new  information  and 
the  capability  of  our  AI  assets  to  flexibly  react  to  a  new  set  of  orders  would 
further  advance  the  ability  of  friendly  ground  forces  to  take  and  maintain 
the  initiative"  (Schoeck,  1987  :  Ch  1,  4).  Three  of  the  pertinent  questions  he 
addressed  include: 

1)  Should  a  set  of  follow-up  missions  be  held  in  reserve? 

2)  When  and  where  should  they  enter  the  battle? 

3)  Should  the  FDO  redirect  an  airborne  aircraft  to  a  new, 
higher  priority  target? 

Schoeck  later  proposes  a  design  for  a  decision  aid  for  the  FDO  to  address 
these  three  and  other  questions  as  they  arise  in  battle.  He  admits  that 
retasking  will  be  difficult  in  a  high  threat  environment  in  which  the  aircrews 
expend  considerable  effort  in  planning  the  original  mission.  What  he  implies 
with  these  suggestions  for  retasking  though,  is  that  with  the  technological 
sophistication  of  the  future,  that  the  FDO,  the  mission  pilot,  and  other 
support  agencies  and  aircraft  may  be  all  linked  through  a  distributed 
decision  support  system  (DSS);  with  this  distributed  system  in  place  his 
proposed  concept  of  dynamic  retasking  becomes  both  feasible  and  a 


productive  alternative  for  tactical  missions. 


Statement  of  the  Problem 

The  ASOC  lacks  the  capability  to  support  the  Army  in  pursuing  the  joint 
objectives  of  the  airland  battle  doctrine.  The  antiquated  manual  procedures 
in  the  current  ASOC  barely  allow  the  personnel  to  keep  up  with  coordinating 
and  tracking  planned  missions.  Improvement  is  needed  in  the  integrated 
employment  of  tactical  airpower  in  support  of  land  warfare  both  at  the  FLOT 
and  the  second  echelon.  Today's  FDO  has  no  support  for  dynamically 
planning  and  either  retasking  or  recommending  retasking  of  both  CAS  and 
BAI  missions.  A  decision  aid  is  needed  to  assist  the  FDO  in  the  ASOC  in 
making  these  dynamic  decisions.  The  FDO  must  be  able  to  view  selected  data 
and  the  ground  situation  to  make  his  decision.  He  may  further  need  the 
support  of  analytical  models  to  test  the  feasibility  of  selecting  different 
options  during  the  initial  planning  and  retasking  processes. 

Research  Objective 

This  researcher  will  investigate  the  possibilities  for  enhancing  the  ASOC 
support  of  the  ground  forces  through  the  use  of  an  automated  DSS.  As  part 
of  this  study,  the  following  sub-objectives  will  be  addressed: 


1)  Determine,  through  use  of  the  technique  of  concept 
mapping  and  discussions  with  experienced  FDOs,  the 
decision  processes  that  the  FDO  in  the  ASOC  makes  in 
his  mission  planning,  coordinating,  and  executing  roles. 

2)  Decide  on  a  critical  or  central  decision  process  ("kernel") 
that  would  benefit  significantly  from  a  decision  support 
aid. 


3)  Translate  the  initial  requirements  gathered  through  the 
procedure  in  sub-objective  1  for  the  critical  decision 
process  into  a  set  of  screen  representations 
("storyboard")  that  the  FDO  can  relate  to  as  the 
possible  steps  of  the  decision  process. 

4)  Evaluate  the  effectiveness  of  the  activities  in 
sub-objectives  1-3  for  quickly  determining  initial 
DSS  requirements,  and  the  ability  to  build  on  these 
initial  requirements. 

5)  Discuss  details  of  the  adaptive  design  approach  within 
this  application  that  facilitate  or  hinder  this 
methodology. 

6)  Provide  an  early  analytical  evaluation  of  the 
preliminary  system  design.  Further  empirical 
evaluations  may  be  possible  as  the  system  prototype  is 
developed. 

7)  Discuss  possibilities  for  enhancing  the  initial  prototype 
design  and  what  developmental  and  organizational 
support  is  needed  for  this. 

The  sub-objectives  above  provide  a  rough  outline  for  an  approach  to 
building  DSSs  called  adaptive  or  evolutionary  design.  The  detailed  techniques 
available  for  adaptive  design  and  the  utility  of  using  it  will  be  discussed  in 
Chapter  II.  Chapter  III  discusses  the  application  of  the  adaptive  design 
process  in  building  the  ASOC  DSS  and  why  it  is  the  method  of  choice.  Chapter 
IV  evaluates  the  resulting  prototype  design.  Chapter  V  provides 
recommendations  on  the  resulting  DSS  design  and  on  the  adaptive  design 
process  in  general. 
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This  chapter  describes  different  approaches  that  could  be  followed  in 
working  toward  a  solution  of  the  problem  presented  in  chapter  I.  Particular 
emphasis  will  be  given  to  the  adaptive  design  and  development  of  decision 
support  systems  (DSSs),  with  reference  to  current  ongoing  research  work  in 
this  area. 


The  following  definitions  are  offered  to  provide  a  common  frame  of 
reference  for  the  discussion  of  different  methodologies  that  follows: 

DSS  -  an  interactive  system  that  provides  the  user  with 

easy  access  to  decision  models  and  data  in  order  to 
support  semistructured  and  unstructured 
decisionmaking  tasks  (Watson  and  Hills,  1 983  :  82). 

DSS  -  a  class  of  information  system  that  draws  on 

transaction  processing  systems  and  interacts  with  the 
other  parts  of  the  overall  information  system  to 
support  the  decisionmaking  activities  of  managers 
and  other  knowledge  workers  in  organizations 
(Spraque  and  Carlson,  1982  :  9). 


Two  definitions  are  provided  because  no  single  definition  was  found  to 

include  all  important  aspects  of  a  DSS;  these  two  definitions  provide  the 

needed  basis  for  the  later  discussion  of  different  methodologies. 

Spraque  and  Carlson's  intent  in  the  second  definition  was  to  eliminate 

several  misconceptions  they  recognized  in  the  familiar  connotational 

definition  of  DSS  that  had  evolved  over  the  years.  First,  Spraque  and  Carlson 

felt  it  is  important  to  realize  that  decision  support  is  required  at  all  levels 
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of  management  in  the  organization.  Second,  the  decisionmaking  which 
occurs  at  various  organizational  levels  must  normally  be  closely  coordinated 
and  communicated  between  these  levels.  These  ideas  about  decisionmaking 
and  required  support  for  it  are  generally  true  both  in  business  and  also  in 
military  C  applications;  acceptance  of  the  two  above  complimentary 
definitions  influenced  the  approach  taken  during  this  project. 

Armed  with  these  two  definitions,  several  current  and  noteworthy  DSS 
research  efforts  are  reviewed  in  the  following  sections.  The  first  effort 
(Hopple)  is  characteristic  of  a  class  of  ongoing  theoretical  decisionmaking 
research  that,  although  it  covers  many  of  the  complicated  issues  involved  in 
this  area,  it  offers  little  concrete  guidance  to  a  designer  of  a  new  DSS.  The 
next  class  of  DSS  research  that  is  discussed  does  offer  specific  guidelines  and 
examples  for  designing  a  C  DSS.  This  latter  work  closely  resembles  the 
current  research  in  DSS  adaptive  design  at  the  Air  Force  Institute  of 
Technology  (AFIT)  under  the  guidance  of  Valusek  (Valusek,  1987:1-16).  An 
examination  of  both  theoretical  issues  and  practical  guidelines  are  included 
to  show  the  complexity  and  difficulty  in  transitioning  from  theory  to  practice 
in  DSS  design. 


Perhaps  a  good  place  to  start  this  section  is  by  reviewing  the  research  of 
Hopple.  This  research  examines  the  dangers  that  may  arise  during  the  initial 
stages  of  the  system  design  and  development  strategy  he  calls  prototyping. 
Figure  2  depicts  the  nine  primary  steps,  and  the  associated  activities  that  a 
DSS  designer  should  follow  at  each  step  of  the  strategy.  The  front-end  of  this 
methodology  (step  1 )  is  somewhat  similar  to  the  concept  exploration  phase 
of  the  defense  system  life  cycle,  with  emphasis  on  feasibility  studies. 
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cost-benefit  comparisons,  and  requirements  definition.  Hopple,  in  his 
discussion  focuses  on  dangers  that  may  arise  during  the  first  three  steps 
"because  the  front-end  steps  are  vital  preconditions  for  the  development  and 
fielding  of  viable  (useful,  usable,  valid,  and  reliable)  C  aiding  systems" 
(Hopple,  1986  :  948).  Unfortunately,  he  barely  addresses  the  specific 
activities  required  in  the  second  step  of  modeling. 

Before  beginning  any  design  or  development  of  a  decision  aid.  Hopple 
cautions  that  rigorous  evaluation  is  needed  to  demonstrate  that  a 
computer-based  system  is  needed  to  solve  the  problem.  Later,  he  calls  for  a 
"theoretically  validated  typology  of  decisions  and  a  coherent  framework  for 
guiding  the  design  process"  (Hopple,  1986:949).  With  this  theoretical 
typology,  a  designer  can  supposedly  assign  a  candidate  problem  to  the 
typology  and  get  an  indication  of  the  best  approach  to  solving  it.  Hopple 
proceeds  at  a  very  theoretical  level  to  lay  the  groundwork  for  building  such 
a  typology  from  C  decisionmaking  theory. 

The  next  step  Hopple  takes  is  to  develop  a  simple  matrix  that  includes  the 
two  types  of  uncertainty  that  may  exist  in  a  C  decision  situation.  Figure  3 
shows  this  matrix.  To  give  an  example  of  a  situation  that  is  represented  by 
quadrant  C  in  the  figure.  Hopple  describes  a  tactical  decisionmaking 
situation  in  support  of  combined  air-land  operations.  Each  of  the  quadrants 
contains  decision  situations  that  are  best  supported  by  different 
decision  aids.  For  example,  decision  aids  for  cell  C  "will  generally  concentrate 
on  the  facilitation  of  understanding  and  meaning  (hypothesis  and  option 
generation,  evaluation,  and  selection)"  (Hopple,  1986  :  950). 


Figure  3.  Basic  Decision  Aiding  Scenarios  (Hopple,  1986:951) 

Those  for  cell  A  will  focus  on  the  "improvement  of  the  battlefield  perception 
process  and  the  enhancement  of  the  quality  of  data"  (Hopple,  1986  :  950). 

This  decision  aiding  scenario  matrix  is  also  used  as  a  basis  to  describe  some 
of  the  particular  problems  that  arise  under  crisis  situation  decisionmaking 
especially  with  the  perceptual  and  cognitive  limitations  of  most 
decisionmakers.  This  discussion  is  also  relevant  to  decisionmaking  and 
DSS,  but  primarily  at  a  theoretical  level. 

One  important  point  that  Hopple  repeats  from  Wohl  is: 

The  preponderance  of  work  in  decision  theory  has  concentrated  on 
techniques  for  option  selection  with  little  research  on  those  portions  of 
the  process  which  are  of  greatest  interest  to  military  commanders, 
namely,  the  creation,  evaluation,  and  refinement  of  both  hypothesis 
(i.e.,  what  is  the  situation)  and  options  (i.e.,  what  can  be  done  about  it) 
(Hopple,  1986  : 952). 

Recognizing  that  a  classical  decision  theoretic  framework  is  not 
appropriate  for  C  decision  situations.  Hopple  continues  by  introducing  a 
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,  decision  situation  typology,  as  shown  in  Figure  4. 
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Figure  4.  Decision  Situation  Typology  (Hopple,  1986:953) 

Hopple  borrows  the  four  following  decision  process  categories  (as  shown  in 
Figure  4)  from  Wohl,  because  he  feels  they  encompass  the  essential 
functions  or  tasks  of  decisionmaking  and  provide  the  essential  link 
between  decision  aids  and  real  world  Qr  decisionmaking: 

1)  stimulus  (data) 

2)  hypotheses  (perception  of  alternatives) 

3)  options  (response  alternatives) 

4)  response  (action) 

The  twenty  Cr  decisionmaking  occasions  that  are  shown  in  the  matrix  in 
Figure  4  "constitute  the  universe  from  which  potential  decision-aiding 
opportunities  or  perceived  needs  arise"  (Hopple,  1986  :  953).  Supposedly, 
the  system  designer  should  be  able  to  determine  the  cells  of  the  matrix  that 


represent  his  current  effort.  As  the  emphasis  shifts  to  the  right  side  of 
Figure  4,  the  "system  designer  and  user  are  both  advised  to  address  the 
question  of  aidability  more  rigorously"  (Hopple  1986  :  953). 

All  of  the  effort  Hopple  has  suggested  so  far  is  intended  as  a  framework 
to  be  used  during  the  requirements  analysis  phase  of  the  nine  step  process 
shown  in  Figure  2.  Overall,  the  following  sequence  of  steps  are  advocated 
for  performing  the  requirements  analysis  (Hopple,  1986  :  954): 

1)  Select  and  define  the  decision  problem. 

2)  Make  a  detailed  description  and  decomposition  of  the 
problem. 

3)  Determine  aidability.  Is  the  domain  aidable?  If  not, 
can  it  be  redefined  to  make  it  aidable  in  whole  or  in 
part? 

Difficulty  in  Applying  Theory.  The  first  two  activities  of  the  sequence 
above  are  extremely  difficult,  if  not  impossible  to  carry  out  during  the  first 
phase  of  the  design  strategy,  as  Hopple  suggests.  The  unstructured  nature 
of  most  C  decisionmaking  scenarios  prevents  the  DSS  designer  from 
defining  and  decomposing  the  problem  at  the  front-end  of  the  project.  The 
suggestion  to  completely  decompose  the  problem  prior  to  proposing  any  DSS 
design  is  unrealistic  as  well  as  inappropriate.  Trying  to  completely  define 
the  problem,  the  user's  requirements,  and  the  system  specification  prior  to 
designing  any  portion  of  the  system  is  a  method  that  may  work  for  well 
understood  automatic  data  processing  (ADP)  type  requirements,  but  is 
ill-suited  to  DSS.  A  more  practical  and  incremental  approach  that  has  proven 
successful  in  building  DSS  is  recommended  by  Andriole  and  other 
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proponents  of  unequivocal  design  techniques  like  adaptive  design.  Before 
delving  into  the  research  on  these  concrete  design  approaches,  some  of  the 
psychological  considerations  in  designing  a  DSS  are  briefly  discussed. 

Psychological  Issues  in  DSS  Design.  A  concern  in  DSS  design  is  how  to 
most  appropriately  assign  the  tasks  to  the  decisionmaker  and  the  system 
that  they  each  perform  most  effectively;  in  other  words  a  splitting  of  the 
decision  tasks  between  man  and  machine.  Hopple  points  out  that  one  of  the 
basic  findings  of  research  is  "that  people  are  susceptible  to  a  number  of 
biases  and  errors  in  describing  and  otherwise  dealing  with  empirical  reality" 
(Hopple,  1986a :  322). 

Specifically,  humans  have  difficulty  applying  statistical  principles;  they 
seem  to  prefer  the  "evidence  of  a  vivid,  concrete  case  over  abstract, 
statistical  information"  (Hopple,  1986a  :  322).  Another  human  weakness  is 
that  people  tend  to  overestimate  the  probability  of  conjunctive  events  and 
underestimate  the  probability  of  disjunctive  events.  Within  the  tactical 
mission  area,  the  overall  success  of  the  mission  is  usually  a  conjunctive 
probability;  each  event  in  a  series  must  occur  for  the  mission  to  be 
successful.  For  a  mission,  success  may  depend  on  the  probabilities  of  the 
aircraft  taking  off,  the  aircraft  getting  to  the  target,  the  weapon  hitting  the 
target,  and  the  aircraft  returning  and  landing  safely. 

Schwartz  and  others  describe  some  related  considerations  in  the  area  of 
"cognitive  systems  engineering  ....  focusing  on  the  cognitive  (i.e.,  mental) 
functions  of  human-machine  systems"  (Schwartz  and  others  1986  :  788). 
They  describe  some  additional  strengths  and  weaknesses  of  humans  and 
systems  which  should  be  considered  during  system  design.  In  the  area  of 
correlation,  humans  are  strong  in  knowing  what  information  to  gather  (data 
relevance),  knowing  to  what  object  a  datum  belongs,  and  integrating 
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data-based  information  (i.e.,  military  doctrine).  On  the  other  hand,  humans 
have  problems  identifying  relationships  and  the  strength  of  relationships. 
Humans  are  also  weak  at  evaluating  data  integrity  (reliability,  consistency) 
and  are  disproportionately  influenced  by  the  way  data  is  presented.  System 
strengths  generally  lie  in  the  areas  mentioned  where  humans  are  weak. 
However,  systems  are  weak  in  situations  which  are  complex  and  generally 
only  "rules  of  thumb"  are  used  (Schwartz  and  others  1986  :  791).  One 
additional  issue  that  Schwartz  briefly  addresses  is  that  the  decisionmaker's 
mental  model,  or  view  of  the  system,  affects  joint  decisionmaker/computer 
system  performance  as  much  as  more  traditional  human  factors  concerns, 
such  as  screen  design,  type  of  interaction,  and  input  devices  (Schwartz  and 
others  1986  :  788).  These  factors  should  definitely  be  considered  in 
designing  the  DSS  dialogue  portion;  the  component  that  the  system  and  user 
need  to  communicate  to  one  another.  Additional  design  features  that 
support  the  cooperative  efforts  of  man  and  DSS  are  addressed  in  the  next 
section. 


If  decision-aiding  technology  seeks  to  support  and  extend  human 
problem-solving  activities,  then  it  must  be  able  to  address  all  of  the 
places  where  human  cognition  is  in  need  of  external  support  (Zachary, 
1986 :  30). 


The  point  to  be  emphasized  in  this  quote  is  the  ability  of  DSS  to  extend  or 

enhance  the  human  problem  solving  activity,  not  merely  automating  the 

activity  through  a  computer  and  thereby  replacing  the  human  in  the  process. 

It  is  generally  recognized  that  by  combining  the  strengths  of  the  human  and 

the  DSS  through  a  sophisticated  interface,  that  both  better  options  can  be 
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generated  and  better  decision  choices  can  be  consistently  selected.  This  is 
achieved  by  building  a  system  that  allows  both  man  and  machine  to  perform 
their  strongest  tasks  during  the  decision  process. 

Representations  Through  Windows.  One  of  the  methods  that  Zachary 
advocates  to  achieve  this  interface  is  to  use  a  representation  aid  or  screen 
display  that  "captures  the  mental  model  used  by  the  expert  decisionmaker 
and  incorporate  it  into  the  interface  as  an  aid  to  the  more  novice  user  of  the 
DSS  "  (Zachary,  1986  :  46).  One  advantage  of  using  the  expen's 
representation  as  the  interface  is  that  the  novice  user  can  "presumably  be 
brought  to  the  expert  level  much  more  quickly  "  (Zachary,  1986  :  46). 

Zachary  also  quite  eloquently  discusses  the  benefits  of  incorporating  a 
windowing  feature  in  a  DSS.  Supposedly,  windows  provide  the  following 
powerful  capability  to  the  decisionmaker: 

By  allowing  the  decisionmaker  to  control  each  window's  spatial 
arrangement,  size,  shape,  and  content,  the  various  windows  become 
visual  metaphors  for  separate  aspects  of  the  decision  problem, 
separate  aiding  functions,  or  separate  tasks  which  may  represent  one 
subproblem  within  the  overall  decision  situation  (Zachary,  1986  :  48). 

By  placing  two  windows  side  by  side  the  decisionmaker  may  be  encouraged 
to  frame  the  problem  differently  than  if  he  were  only  able  to  see  each  of  the 
displays  in  isolation.  Often,  by  visually  combining  the  screen  display 
information  through  a  feature  such  as  windows,  the  decisionmaker  is 
quickly  able  to  make  an  accurate  assessment  of  the  situation,  and  begin  to 
rapidly  formulate  possible  alternatives  to  the  problem. 

Information  Control  Techniques.  Another  group  of  decision-aiding 
technologies  Zachary  discusses  that  are  particularly  vital  in  a  tactical  C“  DSS 
are  the  information  control  techniques.  Three  different  types  of  data  control 


that  are  needed  are  "accessing,  organizing,  and  monitoring"  (Zachary,  1986  : 
38).  Modem  database  management  systems  (DBMS)  allow  a  designer  to 
create  a  database  that  can  be  easily  accessed  by  the  user,  especially  with 
the  natural  language  query  techniques  available.  At  the  next  level  of  data 
control,  important  techniques  that  are  used  to  organize  the  data  are 
automatic  aggregation  techniques.  These  help  to  solve  the  problems  that 
"arise  when  there  are  sharp  level-of -detail  differences  between  the  available 
data  and  the  knowledge  used  in  the  person's  decision  process"  (Zachary, 

1986  :  39).  For  example,  for  a  certain  tactical  mission  requirement,  a  FDO 
may  only  be  able  to  task  aircraft  that  are  on  a  fifteen  minute  or  less  alert 
status.  A  technique  then  would  be  needed  to  organize  or  aggregate  the  data 
according  to  this  criteria.  During  the  third  data  control  stage,  or  the 
monitoring  of  data,  the  user  may  need  alerters,  which  are  "algorithms  that 
monitor  a  dynamic  database  or  datastream  transparently  to  the 
decisionmaker,  looking  for  predefined  key  or  critical  conditions  and  alerting 
the  decisionmaker  when  such  a  condition  is  detected"  (Zachary,  1986  :  39). 
For  example,  the  tactical  planner  may  need  to  be  alerted  when  the  five 
minute  alert  aircraft  that  he  has  available  for  tasking  drop  below  a  certain 
number. 

In  addition  to  presenting  a  thorough  taxonomy  in  decision  aiding 
techniques,  Zachary  also  provides  some  clear  guidelines  in  designing  a 
system  for  a  particular  problem  environment.  One  point  he  emphasizes  is 
that  the  designer  must  consider  the  "decisionmakers  understanding  or 
internal  representation  of  the  problem  environment  and  (the 
decisionmaker's)  implicit  strategies  for  dealing  with  it"  (Zachary,  1986  :  51 ). 
These  guidelines  require  a  method  to  reveal  the  decisionmaker's  "internal 
representation";  guidelines  that  Zachary  does  not  explicitly  provide.  One 


method  that  has  been  suggested  by  McFarren  to  accomplish  this  is  through 
concept  mapping  (McFarren,  1987  :  1-287).  How  to  accomplish  concept 
mapping  will  be  discussed  later  in  this  chapter. 

Representations.  Operations.  Memory  Aids.  ControKROMCl.  Although  the 
research  of  Zachary  revealed  some  explicit  techniques  that  are  needed  to 
design  DSS,  Sprague  and  Carlson  take  it  one  step  further  with  ROMC.  They 
proposed  the  comprehensive  ROMC  approach  to  be  used  during  iterative 
design  of  the  DSS.  By  using  ROMC,  the  evolving  design  remains  decision 
process  independent,  and  so  can  be  used  effectively  by  different  users  in  a 
variety  of  unstructured  decision  processes  (Sprague  and  Carlson,  1982:  Ch  4). 
The  four  components  of  this  approach  are: 

1)  Representations  include  any  graphical  or  text  screen  display  that 
the  user  is  able  to  visually  interact  with,  i.e.,  tables,  graphs, 
maps,  procedural  language  or  other  textual  display. 

2)  Operations  include  system  functions  that  operate  on  the 
representations  and  underlying  data  to  guide  the  user  in 
considering  and  choosing  the  alternatives,  i.e.,  operations  on 
tables,  graphs,  maps,  and  the  database. 

3)  Memory  Aids  include  system  features  that  reduce  the  memory 
load  on  the  decisionmaker,  i.e.,  database  views,  stored  results, 
on-line  help  for  the  user. 

4)  Control  includes  features  that  help  the  user  easily  and  flexibly 
manipulate  the  representations,  operations,  and  memory  aids 
according  to  his  own  style,  i.e.,  menus,  system-user  dialogues, 
and  macro  commands. 

Sprague  and  Carlson's  four  essential  components  provide  the  concrete 
elements  that  a  DSS  designer  needs  to  design  and  begin  to  build  the  system. 
Their  lengthy  and  detailed  documentation  of  the  iterative  design  of  DSS 
business  applications  (Sprague  and  Carlson,  1982),  using  the  four 


components  just  described,  strengthens  the  framework  needed  to  begin 
design  of  a  tactical  military  DSS  application. 

Many  of  the  preceding  theoretical  issues  and  practical  methods  were 
weighed  and  appropriately  applied  during  the  iterative  design  of  a  tactical 
planning  DSS  described  in  the  following  sections;  the  design  approach  taken 
in  this  project  closely  parallels  that  needed  for  the  ASOC  retasking  DSS,  and 
so  provides  a  good  model  to  study. 


Building  a  Real  World  Tactical  Planning  DSS 

Andriole  provides  an  easily  understood  and  documented  approach  to  the 
design  and  development  of  two  tactical  planning  DSSs,  and  offers  a  viable 
approach  for  other  designers.  Although  the  same  overall  nine  step 
structured  methodology  from  Figure  2  was  used  during  the  design  of  two 
systems  named  TACPLAN  and  INTACVAL,  there  was  no  attempt  to 
unrealistically  and  completely  define  user  requirements  up-front.  The  goal 
of  the  effort  was  to  develop  two  decision  aids  "to  support  corps  commanders 
in  the  generation  and  evaluation  of  alternative  plans  or  concepts  of 
operation"  (Andriole  and  others,  1986  ;  854).  The  iterative  nature  of  the 
methodology  of  Figure  2,  as  indicated  by  the  recycling  arrows  on  the  left, 
was  stressed  by  Andriole;  this  methodology  was  justified  for  this  project 
since  the  problem  "domain  was  primarily  cognitive"  (Andriole  and  others, 
1986:854).  In  fact,  Andriole  went  one  step  further  by  describing  the 
methodology  as  "rapid  prototyping".  Some  of  the  techniques  that  were  used 
during  the  project  will  help  to  explain  what  Andriole  means  by  rapid 
prototyping. 

During  requirements  analysis,  two  teams  of  expert  planners  were 
observed  working  through  several  Army  War  College  planning  scenarios.  The 


system  designers  requested  that  the  experts  "think  aloud"  as  they  worked 
through  "protocols  used  to  assess  terrain,  capabilities,  and  courses  of  action" 
in  formulating  their  alternative  plans.  The  sessions  were  video-taped, 
presumably  so  that  no  subtle  yet  significant  steps  in  the  process  were 
missed,  and  so  the  tapes  could  be  later  reviewed  to  check  the 
correspondance  between  the  totally  manual  procedures  and  the  procedures 
being  designed  for  the  new  system. 

An  important  part  of  the  follow-on  modeling  process  involved  the  use  of 
storyboards.  Storyboards  are  described  as  "nothing  more  than  screen 
displays  of  the  functions  and  tasks  that  the  aid  might  perform  when 
activated  by  a  user"  (Andriole  and  others,  1986  :  855).  The  power  of 
storyboards  is  best  summed  up  in  the  following  words  of  the  researchers: 

The  storyboarding  exercise  enabled  us  to  validate  requirements, 
identify  some  totally  new  ones,  experiment  with  some  alternative 
man-machine  interface  (MMI)  techniques,  and  -  most  importantly  - 
select  the  analytical  methods  most  likely  to  help  drive  the  aid," 
(Andriole  and  others,  1986  :  855). 

Through  the  storyboarding  process,  it  was  decided  that  the  system  would 
initially  use  both  decision  analytic  and  artificial  intelligence  methods. 
Another  system  feature  that  was  validated  during  this  modeling  phase  was 
the  use  of  video  disks  to  display  actual  maps  of  the  Corps  area  of 
responsibility,  at  near  perfect  resolution.  The  strengths  that  video  disk 
technology  supported  during  this  project  included:  (1)  the  ability  to  create 
one's  own  personal  symbols  for  annotation,  (2)  decluttering,  or  the  ability  to 
selectively  display  a  portion  of  the  map's  annotations  at  a  time,  and  (3)  the 
ability  to  quickly  "fly  around"  a  map  and  zoom-in  on  selected  locations  if 
desired.  The  most  important  capability  that  video  disks  added  to  TACPLAN 


was  identified  as  the  "ability  to  communicate  symbolically  with  both  the 
planner  and  the  analytical  side  of  TACPLAN"  (Andriole  and  others,  1986  : 
858).  For  example,  if  a  planner  illustrates  an  enemy  course  of  action  by 
drawing  it  on  the  display,  TACPLAN  immediately  knows  something  about 
the  course  of  action.  This  is  possible  because  coordinates  on  the  video 
display  are  linked  to  analytical  routines  and  knowledge  bases  stored  in 
TACPLAN  (Andriole  and  others,  1986  :  858).  The  planner  is  allowed  to  make 
"wholesale  judgements  about  area  characteristics,  mission,  and  doctrine, 
and  then  subjects  these  judgements  to  what  is  contained  in  the  knowledge 
bases"  (Andriole  and  others,  1986  :  858). 

What  was  strongly  suggested  through  this  work  is  that  "tactical  planning 
is  inherently  graphic  and  non-numeric.  When  planners  plan,  they  move 
icons,  refer  to  illustrations,  draw  courses  of  action  and  argue  via  references 
to  pictures,  graphs,  and  lines"  (Andriole  and  others,  1986  :  863).  The  work 
of  this  team  is  important  for  several  other  reasons  as  well.  Their  overall 
iterative  approach  and  early  prototype  testing  revealed  that  a  refinement  in 
the  role  the  decision  aid  should  play  in  the  planning  was  needed,  and  so 
ENTACVAL  actually  evolved  out  of  TACPLAN.  This  was  a  validation  of  the 
feasibility  of  prototyping  for  refining  system  requirements  as  the  system 
was  evolving.  Another  concept  they  verified  was  the  use  of  microcomputers 
to  support  this  C^  tactical  planning  process.  Previously,  the  process  had 
been  done  strictly  manually.  Lastly,  the  benefits  derived  from  their 
requirements  and  modeling  phases  via  storyboarding  provide  valuable  ideas 
for  further  research  and  related  tactical  projects.  Almost  all  of  these 
techniques  can  also  be  applied  to  design  of  the  ASOC  DSS.  The  approach 
selected  to  design  the  ASOC  DSS  is  based  on  the  theory  that  has  been 
discussed  here  and  on  continuing  research  in  adaptive  design  at  AFIT.  The 


remainder  of  this  chapter  looks  at  the  specific  techniques  that  characterize 
adaptive  design,  and  how  and  why  the  methodology  has  been  applied. 

Adaptive  Design 

Adaptive  design  is  an  iterative  approach  which  combines  the  four 
traditional  system  development  activities  (requirements  analysis, 
design,  development,  and  implementation)  into  a  single  phase  which 
is  repeated  over  short  intervals.  The  "major  components  of  adaptive 
design  include  the  builder,  the  user,  and  the  technical  system 
(DSS)"  (Alavi  and  Napier,  1984  :  22). 

Adaptive  design  as  a  process  seems  to  mesh  well  with  decision 
problems.  There  is  a  close  alignment  between  the  methods  of  the  approach 
and  the  way  users  seem  to  think  about  the  decision  problem  that  they  need 
the  DSS  for.  Specifically,  adaptive  design  starts  at  the  user  location  with  a 
gradual  development  of  the  DSS  around  a  central  decision  process,  or 
"kernel"  (Valusek,  1987  :  5).  One  of  the  more  difficult  phases  of  the 
approach  is  establishing  the  initial  kernel  and  storyboard  set.  With  these  in 
place  though,  there  is  an  easily  understandable  and  modifiable  framework 
from  which  the  DSS  can  grow.  At  this  point,  the  adaptive  approach  begins  to 
feed  on  itself.  The  initial  system  kernel  and  storyboard  provide  food  for 
thought,  and  stimuli  for  further  design  ideas  both  for  the  user  and  the 
designer/  builder.  Future  DSS  enhancements  and  refinements  are  developed 
and  maintained  by  the  user  in  what  is  described  as  the  "hookbook”  (Valusek, 
1987  :  10).  The  hookbook  is  a  method  (manual  or  computer-supported)  to 
record  design  ideas  for  the  evolving  DSS  as  they  come  to  mind.  Individual 
entries  to  the  hookbook  are  made  on  notecards  as  shown  in  Figure  5.  The 
"idea"  and  "circumstances"  under  which  the  idea  occured  are  all  that  needs  to 


to  assign  "labels",  to  assist  in  classifying  the  growing  number  of  ideas.  The 
user  maintains  the  hookbook  and  storyboard,  refining  them  based  solely  on 
his  needs;  the  DSS  is  actually  being  built  several  iterations  behind  the 
current  version  of  the  storyboard. 


Most  importantly,  the  adaptive  design  framework  and  initial  design 
provides  "a  communication  anchor  between  all  parties  both  to  enable  and 
enhance  a  meaningful  dialogue"  (Boar,  1984  :  7-8).  Boar  sees  this 
communication  as  vital  and  emphasizes  that  all  analysis  techniques  to  date 
have  failed  to  address  adequately  that: 


(1)  Users  have  extreme  difficulty  in  prespecifying  in  total  and  final 
detail  their  requirements. 

(2)  Miscommunication  is  endemic  between  project  members. 

The  adaptive  design  approach  described  in  this  thesis  includes  tools  and 
methods  to  address  both  of  these  formidable  problems,  not  only  during 
initial  system  analysis,  but  throughout  the  life  of  the  evolving  DSS. 

Adaptive  design  is  ideal  for  DSS  development  because  its  structure  allows 
the  system  to  evolve  based  on  the  decisionmaker's  thought  and 
decisionmaking  processes.  For  the  generally  unstructured  decisions  of 
retasking  and  rapid  replanning  in  the  ASOC,  adaptive  design  provides  the 
potential  to  create  a  system  kernel  and  a  strong  mechanism  for  further 
enhancing  the  support  of  the  decisions.  The  specific  techniques  that  are 
needed  for  this  design  process  arq  described  below. 


Kgrngl  Identification  Through  Concept  Mapping.  Concept  mapping  is  an 
educational  tool  that  has  been  recently  applied  to  system  design  and 
development  by  McFarren,  to  assist  in  revealing  early  system  requirements. 
Concept  maps  are  literally  "schematic  devices  to  represent  a  set  of  concept 
meanings  embedded  in  a  framework  of  propositions"  (  Novak  and  Gowin, 
1984).  Within  education,  concept  maps  provide  a  number  of  key  ideas  that 
must  be  focused  in  on  for  a  learning  task,  and  also  a  summary  of  what  is 
known  or  understood  by  the  student. 

In  McFarren's  work,  the  concept  map  was  used  to  reveal  experts' 
understanding  of  a  particular  process  or  decision  that  they  were 
accomplished  in.  The  process  of  actually  sitting  down  with  the  expert  and 
drawing  out  the  concept  map  is  often  found  to  reveal,  even  to  the  expert, 
relationships  between  the  concepts  that  he  may  not  have  known  existed 


(Novak  and  Gowin,  1984).  This  particular  finding  is  important  because  of  the 
difficulty  in  defining  all  the  important  aspects  of  a  complex  decision  process, 
and  thus  the  requirements  that  a  DSS  should  support  if  it  is  to  be  used 
during  the  decision  process. 

McFarren  has  also  found  through  extensive  concept  mapping  of  Air  Force 
experts  that  maps  of  different  experts  can  be  overlaid  as  another  means  to 
expose  common  schemes  in  their  maps.  These  common  portions  of  different 
maps  may  well  be  suitable  points  at  which  to  begin  development  of  the  DSS; 
these  portions  of  the  maps  may  also  be  called  kernels.  Just  as  concept  maps 
have  been  suggested  as  "useful  tools  to  help  students  negotiate  meanings 
with  their  mentors"  (Novak  and  Gowin,  1984),  they  can  also  be  used  as  tools 
to  exchange  ideas  and  promote  dialogue  between  a  user  and  a  system 
designer  adaptively  designing  a  new  DSS. 

Storvboarding  foi  Refining  Requirements.  Andriole  has  been  successful 
in  identifying  and  refining  system  requirements  throughout  the  life  of  a  DSS 
project  through  the  use  of  storyboards. 

Storyboards  can  be  used  to  verify  system  requirements  definitions, 
tailor  design  specifications,  and  direct  the  software  engineers  in  a  full-blown 
design  project.  Storyboards  are  used  primarily  as  a  modeling  tool  in  this 
research  project.  From  the  storyboards,  the  partial  system  requirements 
and  design  specifications  for  the  evolving  system  are  later  shaped,  or 
developed. 

Users  and  technical  staff  involved  in  a  DSS  project  must  review  the 
storyboards  at  regular  intervals  to  provide  their  inputs  for  changes  or 
updates.  This  process  continues  throughout  the  life  of  the  DSS.  It  has  been 
suggested  that  the  "design  team  -  in  conjunction  with  users  -  develop  a  set  of 
displays  that  represent  each  and  every  path  users  might  take  once  the 


system  is  developed"  (Andriole  and  others,  1987: _ ).  A  path  refers  to  an 

option  or  alternative  that  the  decision  maker  has  in  solving  the  problem. 

Storyboard  Testing.  Once  the  sequence  of  storyboards  are  designed 
and  prepared,  they  need  to  be  tested  by  the  user(s).  Each  user  who  is 
evaluating  the  storyboards  can  accomplish  this  using  the  microcomputer 
prototype  if  available,  while  making  annotations  on  a  hard  copy  of  each  of 
the  storyboards.  Andriole  further  suggests  that  it  may  be  helpful  to  also 
tape  record  the  evaluators  comments  as  they  are  working  through  the 
system,  although  this  may  not  be  practical  under  all  situations. 

After  a  test  run,  necessary  changes  are  made  to  the  storyboards  and 
more  tests  conducted.  The  final  goal  in  this  process  is  to  have  a  "consensus 
emerge  about  what  the  system  should  do  and  how  it  should  do  it"  (Andriole 

and  others,  1987: _ ).  During  this  process  not  only  is  the  sequence  of 

storyboards  improved,  but  any  problems  with  the  man-machine  interface 
can  be  resolved  at  the  same  time. 


Storvboarding  Conserves  Resources.  Storyboarding  is  an  adaptive  design 
technique  that  produces  a  rough  draft  of  a  design  using  minimal  amount  of 
user  time,  and  with  minimal  expense.  It  also  guards  against  getting  started 
in  the  wrong  direction  or  defining  system  requirements  inaccurately. 


Expenses  are  kept  low  with  storyboarding  because  the  screens  are  generally 
developed  using  off-the-shelf  software  that  runs  on  a  microcomputer. 


Andriole  suggests  an  Apple  Macintosh™,  which  can  produce  some  fairly 
sophisticated  screens  using  software  that  is  tailor-made  for  storyboarding. 
Andriole  further  points  out  that  with  storyboarding,  "the  potential 


dividends  are  enormous"  (Andriole  and  others,  1987  .11). 


From  a  technical  perspective,  storyboarding  permits  the  verification 
of  requirements  via  direct  linkage  with  intended  users,  while  from 
management's  perspective  storyboarding  permits  phased,  iterative, 
cost-effective  systems  design  and  development;  it  also  yields  a 
product  early  in  the  systems  design  and  development  process. 
(Andriole  and  others,  1987  :  1 1). 

Outline  for  Chapter  III 

Chapter  III  of  this  thesis  discusses  application  of  the  general  design 
framework  and  guidelines  for  adaptive  DSS  design  reviewed  in  this  chapter, 
to  the  specific  problem  in  the  ASOC;  the  retasking  of  CAS  and  BAI  missions 
in  a  tactical  C  environment. 


The  problem  that  exists  in  the  ASOC  of  the  TACS  is  the  lack  of  an  effective 
method  or  system  to  assist  in  decisions  that  are  made  about  retasking  of  CAS 
and  BAI  missions.  Given  the  quickly  changing  ground  situation  of  today’s 
airland  battlefield,  it  is  hypothesized  that  air  support  will  have  to  be  ready 
to  flexibly  respond  to  this  dynamic  situation  to  be  effective.  Although 
preplanning  at  staff  and  unit  level  will  still  remain  an  important  part  of  each 
mission,  the  need  to  rapidly  replan,  possibly  retask,  and  then  execute  the 
new  mission  from  the  ASOC  level  will  be  necessary.  Future  intelligence 
sensors  currently  on  the  design  boards  will  be  able  to  provide  a  real-time 
picture  of  the  enemy's  initiatives.  With  this  information,  it  will  be  possible 
to  not  only  react  to  the  changing  ground  situation,  but  also  to  be  able  to  plan 
initiatives  to  prohibit  the  enemy  from  executing  his  plan.  Combining  this 
technological  capability  with  the  dynamic  battle  situation  and  changing 
target  priorities  underscores  the  requirement  for  rapid  retasking. 

Generally,  many  of  these  rapid  retasking  situations  will  be  considered 
crisis  situations,  in  which  there  exists  varying  degrees  of  uncertainty  in  data 
input  and  option  outcome.  Using  Hopple's  suggested  typology  from  Chapter 
II,  these  crisis  situations  are  appropriate  for  the  use  of  a  DSS. 

The  specific  problem  situation  in  the  ASOC  seems  to  fall  somewhere 
between  quadrant  A  and  quadrant  C  of  Hopple's  Decision  Aiding  Scenarios 
matrix  in  Figure  3.  By  performing  some  decomposition  of  the  retasking 
problem,  it  is  likely  that  the  input  data  quality  will  vary  between  the  high 
and  the  low  end  of  the  matrix,  depending  on  many  variables  involved  in 
collecting  the  data  and  disseminating  it  to  the  agencies  that  need  it.  On  the 


Figure  3.  Basic  Decision  Aiding  Scenarios  (Hopple,  1986:951) 


other  hand,  the  options  available  to  the  ASOC  decisionmaker  in  either 
recommending  or  performing  the  retasking  are  fairly  limited.  There  are  a 
limited  number  and  type  of  aircraft  that  will  be  available  for  CAS  and  BAI 
retasking,  and  an  equally  limited  number  of  options  for  how  they  might  be 
used,  depending  in  part  on  their  weapon  configurations  and  delivery 
systems.  Thus,  the  decision  will  normally  fall  within  the  fixed  options 
portion  of  Hopple's  matrix.  Based  on  these  assumptions  about  the  decision 
aiding  scenario.  Hopple  states  that  scenarios  falling  into  this  general 
category  on  the  matrix  can  be  best  aided  by  a  DSS  that  focuses  on  the 
"improvement  of  the  battlefield  perception  process  and  the  enhancement  of 
the  quality  of  data"  (Hopple,  1986  :  950).  Despite  the  fact  that  the  options 
will  generally  be  limited,  the  DSS  should  be  designed  to  work  effectively 
with  a  greater  range  of  options.  As  more  resources  become  available  to  the 
decisionmaker  for  retasking,  the  DSS  needs  to  support  the  evaluation  and 
selection  of  the  best  option  from  the  total  range  of  options.  For  example,  the 
DSS  should  adapt  equally  well  to  weapon  constrained  or  weapon-rich 


situations. 

With  this  established  requirement  for  retasking,  there  is  a  need  to 
discuss  the  reasons  why  an  adaptive  design  process,  that  incorporates 
prototyping,  is  the  most  appropriate  approach. 

Why  Adaptive  Design  is  Needed 

Assuming  that  one  of  the  significant  advantages  of  using  adaptive  design 
is  the  ability  to  respond  to  changing  and  evolving  system  requirements,  it  is 
necessary  to  examine  how  this  advantage  will  support  the  retasking 
requirement  in  particular. 

New  Doctrine.  Officially,  the  concept  of  dynamic  retasking  being  done 
by  the  ASOC  is  not  currently  recognized,  despite  the  fact  that  considerable 
retasking  has  occurred  in  recent  conflicts.  Retasking  of  air  interdiction  assets 
has  also  been  discussed  in  detail  in  a  recent  AFIT  thesis  (Schoeck,  1986). 

Retasking  is  even  more  viable  from  the  Airborne  Command  and  Control 
Center(ABCCC),  which  occasionally  serves  as  an  airborne  ASOC.  The  ABCCC, 
because  of  its  orbiting  position,  generally  would  have  access  to  the  real-time 
mission/aircraft  information  that  would  permit  the  decisionmaker  to  make 
some  smart  retasking  decisions.  Without  a  retasking  DSS,  the  potential  for 
increased  effective  use  of  forward  aerial  control  from  the  ABCCC  is  wasted. 

Despite  these  arguments,  retasking  is  generally  only  briefly  mentioned 
or  alluded  to  in  official  Air  Force  regulations,  and  then  without  any 
explanation  as  to  how  the  retasking  might  be  accomplished.  There  are  a 
number  of  knowledge-based  planning  DSSs  being  built  for  the  long  range 
planning  cycles  in  the  TACS.  Many  of  these  systems  will  allow  the  planner 
the  capability  to  consider  different  options  and  examine  the  trade-offs  of 
several  different  plans  before  one  is  decided  on.  However,  little  emphasis 
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has  been  given  to  the  similar  problem  that  faces  those  executing  planned 
missions  in  which  alternate  planning  is  required  "on  the  fly",  because  the 
original  mission  cannot  be  executed  exactly  as  planned.  Some  of  the  primary 
triggers  that  may  necessitate  the  need  to  retask  include: 

1)  predicted  targets  do  not  materialize 

2)  predicted  targets  are  different  than  expected 

3)  predicted  targets  cannot  be  attacked  due  to 
environmental  conditions 

4)  priorities  change 

5)  another  target  of  opportunity  arises 

6)  status  of  weapon  delivery  platform  changes 

Because  this  dynamic  retasking  concept  has  not  been  formally  addressed  by 
the  TAC  staff  and  other  interested  policymaking  organizations,  there  is 
bound  to  be  a  considerable  amount  of  negotiation  and  reworking  of  the  issue 
as  planners  begin  to  address  the  deficiencies  that  currently  exist.  A  DSS  that 
can  evolve  with  the  corresponding  evolving  doctrine  in  this  area  is  required. 

Different  Theaters.  Another  reason  for  adaptive  design  is  the  fact  that 
the  operation  of  the  TACS,  and  the  ASOC  in  particular,  varies  from  theater 
to  theater.  The  organizational  alignment,  the  specific  tasks,  the  system  and 
agency  interfaces  are  all  slightly  different  from  one  place  to  another.  What 
must  be  agreed  upon  then,  is  a  generic  model  around  which  the  retasking 
DSS  can  be  designed.  This  researcher  has  attempted  to  define  this  generic 
model  and  use  a  general  approach  in  designing  the  retasking  DSS;  the  goal  is 
to  be  able  to  test  the  feasibility  of  the  DSS  in  a  variety  of  theaters  and 
scenarios.  Tailoring  of  the  generic  DSS  to  best  match  each  of  the  theater's 


.  !*■  a 


needs  will  be  a  later  refinement  to  the  basic  system  that  should  be  possible 
using  the  adaptive  approach  in  each  theater. 

Need  tQ  Integrate  CAS  and  BAI.  Another  factor  that  must  be  considered 
is  the  evolving  role  of  the  Air  Force  in  the  Airland  Battle  planning  and 
execution.  As  previously  mentioned,  there  is  a  recognized  need  by  the 
Army  to  better  integrate  the  close-in  and  second  echelon  targets  on  the 
battlefield.  This  equates  to  CAS  and  BAI  targets  that  the  Air  Force  may  be 
requested  to  hit.  It  seems  logical  that  not  only  the  long  range  planning,  but 
also  the  more  immediate  missions  including  the  retasking  of  missions,  must 
be  integrated.  Since  little  integration  seems  to  have  occurred  in  the  past 
between  CAS  and  BAI  missions,  there  will  likely  be  extensive  study  and 
discussion  on  this  issue.  Consequently,  any  DSS  developed  for  ASOC  use  will 
have  to  be  changed  as  requirements  in  this  area  also  evolve. 

Different  User  Inputs.  Besides  the  more  doctrinal  issues  discussed  above, 
there  are  a  host  of  more  practical  reasons  to  advocate  adaptive  design.  This 
researcher  has  already  experienced  one  of  these  reasons  in  working  with  the 
potential  system  users  at  different  organizational  levels.  Most  of  the 
operational  requirements  for  the  ASOC  are  generated  at  TAC  Headquarters, 
while  the  greatest  user  experience  and  familiarity  with  the  missions  exists  at 
each  of  the  ASOCs  at  9th  Air  Force,  and  12th  Air  Force.  The  system  builder 
must  work  with  these  different  organizational  "users”  to  get  the  best  starting 
point  for  a  generic  system.  Throughout  the  life  cycle  of  the  DSS,  it  is  likely 
that  a  comparison  of  the  requirements  generated  at  the  different 
organizational  levels  will  sometimes  conflict,  or  may  sometimes  be  too 
detailed  for  a  generic  design;  in  all  of  these  instances  the  need  for  adaptive 
design  becomes  apparent. 

Funding  Lgvgjs  Vary.  Another  practical  consideration  has  to  do  w; *  n 
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funding  for  a  program;  one  year  it  may  be  impossible  to  spend  all  the 
money  allocated,  and  the  next  the  funding  may  literally  dry  up.  Since 
funding  for  military  programs  is  highly  variable,  it  makes  sense  to  develop 
the  system  by  starting  small  and  growing.  Using  an  adaptive  approach 
avoids  spending  an  exorbitant  amount  of  money  on  the  conceptual  design 
and  then  not  being  able  to  implement  any  of  the  program  because  of  funding 
problems.  A  related  benefit  can  be  realized  if  an  initial  incorrect  design  is 
generated.  Because  the  adaptive  design  process  forces  the  design  of  a  small 
portion  of  the  system  at  a  time,  there  will  be  a  minimun  amount  of  wasted 
resources  if  an  evaluation  uncovers  a  poor  design. 

Selection  of  Kernel.  Another  important  benefit  of  the  adaptive  design 
process  for  the  retasking  problem  is  the  selection  of  the  critical  or  most 
important  kernels  at  the  beginning.  Since  the  system  should  be  functional, 
in  a  limited  manner,  with  the  first  testable  prototype,  the  user  and  builder 
are  compelled  to  decide  on  an  initial  design  that  can  actually  be  used  for  a 
retasking  decision  when  implemented.  For  the  problem  of  retasking  in  the 
ASOC,  the  initial  kernel  includes  an  aircraft/ weapon  representation  or 
screen,  a  target  representation,  and  a  ground  situation  representation.  By 
using  these  in  an  integrated  manner,  the  FDO  in  the  ASOC  can  evaluate  the 
situation  and  generate  possible  courses  of  action.  The  complete  detailed 
range  of  operations  or  control  mechanisms  that  may  be  needed  in  the 
retasking  DSS  are  not  all  known  at  this  time.  Generally,  only  by  working 
with  the  user  over  time,  will  the  builder  and  user  perceive  requirements  for 
analytical  models  or  appropriate  knowledge-based  techniques  within  the 
system. 

Testing  the  Prototype.  The  approach  that  TAC  is  planning  during  the 
TBM  program  will  mesh  perfectly  with  an  adaptive  design  for  the  ASOC 


retasking  DSS.  As  mentioned  in  Chapter  I,  the  plan  is  to  bring  new  TACS 
software  modules  on-line  incrementally,  after  joint  testing  at  the 
prototyping  facilities  at  Langley  AFB  and  Hanscom  AFB.  The  prototyping 
testbeds  provide  the  needed  central  facility  to  do  extensive  testing  and 
evaluation  of  the  software  systems  under  development.  These  testbeds  will 
allow  major  software  problems  to  be  solved  and  refinements  to  be  quickly 
made  before  the  systems  are  fielded;  potentially  maximizing  user 
satisfaction  with  each  fielded  software  version.  The  central  prototyping 
facility  will  conserve  resources,  flush  out  unnecessary  or  error-prone 
portions  of  the  initial  system,  and  allow  integrated  testing  with  the  other 
developing  software  systems  of  the  TACS.  The  central  facility,  if  managed 
correctly,  will  make  it  easier  for  contractors  developing  the  systems  to 
respond  to  users'  needs  because  users  will  be  heavily  involved  in  all  phases 
of  the  process;  all  communications  between  the  user  and  the  DSS  builder 
should  be  coordinated  through  this  central  facility. 

Instead  of  hindering  the  transition  from  the  use  of  strictly  traditional 
system  design  methods  to  adaptive  design,  the  prototyping  facility  should 
ease  the  transition;  it  will  satisfy  the  needs  of  managers  who  are  responsible 
for  central  system  software  maintenance  and  control.  Using  this  central 
prototyping  facility  for  software  control  and  testing  will  not  interfere  with 
the  activities  that  the  user  is  responsible  for  at  his  own  site  under  adaptive 
design.  The  problem  of  choosing  which  users  to  bring  to  the  prototyping 
facility  should  be  handled  by  a  "referee"  at  TAC;  he  should  make  these 
decisions  based  on  the  contributions  that  individual  users  can  make  to  the 
evolving  DSS  and  the  diversity  of  ideas  that  can  be  generated  by  using  a 
great  variety  of  users  with  diverse  backgrounds.  Further  discussion  on  the 
role  of  the  referee  is  included  in  Chapter  V. 
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Actual  System  Design 

Concept  Mapping.  As  a  tool  to  try  to  reveal  the  full  range  of  elements  or 
concepts  that  experts  consider  in  planning  an  air  support  mission  in  the 
ASOC,  the  concept  mapping  approach  was  used.  An  operational 
requirements  expert  and  experienced  FDO  at  TAC  Headquarters,  and  an 
experienced  FDO  at  the  682  ASOC,  Shaw  AFB  were  used  for  this  exercise.  At 
the  time  the  concept  maps  were  created,  the  ASOC  retasking  decision 
problem  had  not  yet  been  identified,  so  the  maps  do  not  particularly  focus 
on  the  retasking  decision  process.  However,  the  concept  maps  do  identify 
many  of  the  critical  elements  involved  in  planning  and  coordinating  ASOC 
missions  under  less  of  a  crisis  environment  than  the  retasking  decisions. 

Despite  the  emphasis  of  the  concept  mapping  exercises  and  the  resulting 
maps  that  were  accomplished,  many  of  the  revealed  concepts  also  can  be 
applied  to  the  retasking  decision  process.  In  fact,  the  concept  map  with  the 
expert  at  TAC  centered  on  BAI  mission  planning.  Generally,  there  will 
probably  be  more  time  for  decisionmaking  during  retasking  of  BAI  missions 
versus  retasking  of  CAS  missions,  primarily  because  of  the  difference  in 
distances  between  aircraft  and  potential  targets  in  the  two  different 
missions.  It  is  possible  that  some  of  these  concepts  from  the  original  map  for 
BAI  planning  will  be  applicable  to  either  retasking  or  recommending 
retasking  of  BAI  missions.  The  two  original  maps  that  were  created  appear 
in  Figures  6  and  7. 


Building  lh£  Storyboard.  Based  on  the  ideas  generated  from  the  concept 
maps  and  further  information  gathered  during  visits  to  TAC/DOYF  and  the 
682  ASOC/DO,  this  researcher  generated  several  preliminary  storyboards 
representing  critical  elements  of  the  decision  process  used  during  retasking. 
From  these  conversations  with  experts,  it  seems  likely  that  the  vast 
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majority  of  times  that  retasking  situations  might  arise  would  be  triggered  by 
some  sort  of  change  to  the  target  or  target  area.  As  stated  officially  in  the 
General  Operating  Procedures  for  the  Joint  Attack  of  the  Second  Echelon 
(J-SAK)  and  verified  by  experienced  FDOs,  the  following  prioritized  list  of 
triggers  may  necessitate  the  need  to  retask: 

1)  priorities  change 

2)  another  target  of  opportunity  arises 

3)  predicted  targets  do  not  materialize 

4)  predicted  targets  are  different  than  expected 

5)  predicted  targets  cannot  be  attacked  due  to 
environmental  conditions 

The  J-SAK  procedures  pamphlet  further  states  that  the  TACC  will  evaluate 
the  new  target  for  compatibility  with  planned  sorties.  Principal 
considerations  are: 

1)  Can  the  new  target  be  attacked  effectively  with  planned  ordnance? 

2)  Can  the  mission  be  accomplished  without  unacceptable  losses? 

3)  Is  there  sufficient  time  to  notify  the  various  support  elements  of 
the  force  package  or  can  a  mission  be  flown  without  support? 

4)  Will  the  change  allow  aircrews  sufficient  time  for  planning? 

Although  the  TACC  is  supposed  to  consider  these  questions,  it  is  often  the 

ASOC  that  can  provide  better  answers;  in  the  case  of  CAS,  the  ASOC  executes 

the  mission  and  in  the  case  of  BAI,  the  ASOC  accomplishes  much  of  the 

initial  planning  and  mission  following.  Even  if  authority  to  retask  or  divert 
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remains  only  at  the  TACC  level,  a  recommendation  from  the  ASOC  on  the 
retasking  decision  will  be  necessary.  Consequently,  the  FDO  working  in 
concert  with  the  G-3  Air  in  the  ASOC  will  be  required  to  answer  these 
questions  and  make  the  recommendation.  Naturally,  the  decisions  to  be 
made  in  the  ASOC  will  revolve  around  these  same  questions,  and  the 
necessary  DSS  representations  should  be  designed  to  support  the  answering 
of  these  questions  and  making  these  decisions. 

To  address  the  first  consideration  listed  above,  the  aircraft/ordnance 
that  have  been  allocated  to  the  Corps  and  are  available  for  retasking  should 
be  scanned  to  see  if  effective  ordnance  against  the  new  target  is  available.  It 
is  necessary  to  support  the  FDO  with  embedded  weaponeering  operations 
that  present  feasible  weapon  alternatives.  To  decide  whether  losses  can  be 
minimized  to  an  acceptable  level,  it  is  likely  that  the  FDO  will  examine  the 
ground  situation,  paying  particular  attention  to  threats  the  aircraft  may 
encounter.  Weather  also  plays  a  significant  role  in  this  portion  of  the 
decision  process;  i.e.,  can  the  ordnance  be  delivered  effectively  with  the 
given  weapon  and  delivery  system  under  the  current  weather  conditions? 
The  chances  of  missing  the  target  altogether  and  wasting  the  ordnance 
should  be  considered. 

Some  of  the  BAI  missions  will  require  some  degree  of  support  either  on 
the  ground,  or  airborne,  or  a  combination  of  both.  With  retasking  or 
diverting,  the  question  of  notifying  and  repositioning  support  elements  must 
be  considered.  The  FDO  may  need  to  review  the  support  elements  that  were 
tasked  against  the  initial  mission  to  decide  if  any  of  these  can  be  shifted  to 
the  new  mission.  If  not,  and  it  is  decided  that  their  type  of  support  is  still 
essential  with  the  new  mission,  replacements  will  have  to  be  generated. 

This  will  most  likely  involve  another  survey  of  the  ground  situation  for 


ground  support  and  possible  review  of  available  airborne  support.  Whether 
all  the  coordination  with  the  support  elements  can  be  accomplished  prior  to 
the  mission  will  become  a  primary  consideration. 

Technological  Limitations  on  the  Kernel.  With  current  technology,  it  is 
unlikely  that  retasking  will  allow  aircrews  sufficient  time  for  replanning, 
unless  of  course  the  mission  scenario  is  limited  and  planned  for  a  low  threat 
target  area.  This  inability  of  the  aircrew  to  rapidly  replan  will  provide  a 
significant  hindrance  to  the  possibility  of  retasking  and  diverting  missions, 
until  technology  allows  mission  planning  to  be  accomplished  "on  the  fly", 
through  a  sophisticated  integration  of  pilot,  aircraft  system,  and  ground 
systems.  Nonetheless,  planning  for  this  eventuality  should  continue. 

Ground  Situation  Display.  With  the  initial  emphasis  for  the  DSS  on  the 
decision  tasks  previously  discussed,  there  appears  to  be  a  heavy 
dependence  on  a  geographic  ground  situation  representation.  This 
requirement  was  validated  by  all  experts  that  made  inputs  to  the  retasking 
design.  The  idea  of  using  a  high  resolution  video  disk  to  display  actual 
geographic  maps,  with  the  ability  to  selectively  display  pertinent  symbols, 
and  link  appropriate  nongraphical  data  with  the  graphical  display,  was 
inherently  appealing  to  all  experts  that  made  inputs  to  the  design;  most 
experts  felt  that  a  display  of  this  sort  was  absolutely  necessary.  Considering 
the  validated  results  of  Andriole's  work  with  video  disk  displays  used  in 
airland  battle  planning,  it  was  decided  this  would  be  a  beneficial  feature  of 
the  retasking  DSS  as  well.  Because  of  the  close  coordination  between  Army 
and  Air  Force  during  CAS  and  BAI  missions,  it  was  also  decided  that  the 
geographic  displays  the  Army  uses  would  be  the  most  helpful  during  the 
retasking  decisions.  The  ability  to  zoom  into  a  certain  area  of  a  map  and 
display  finer  detail  was  mentioned  as  a  desirable  feature;  this  feature  was 


CM 


Mb 


v.v.'A 


nvnmmnim 


included  in  the  storyboard.  Based  on  the  expected  need  for  the  FDO  to  use 
the  full  geographic  display  during  several  different  phases  of  the  decision 
sequence,  it  is  believed  that  a  separate  geographic  display  is  needed,  on  a 
separate  screen  from  the  other  decision  screens  that  are  used.  It  is  also 
envisioned  that  the  representations  of  aircraft/weapon  and  target  data  will 
need  to  be  examined  either  simultaneously,  or  back  to  back.  One  good  way 
of  offering  this  feature  is  through  either  a  split  screen  representation  or  the 
capability  to  use  windows  for  the  different  database  relations  and  other 
displays.  The  flexibility  inherent  in  windowing  influenced  the  incorporating 
of  this  feature  in  the  kernel  DSS. 

Specific  Kernel.  The  specific  kernel  is  based  on  the  six  primary  retasking 
triggers  earlier  descibed  as: 

1)  priorities  change 

2)  another  target  of  opportunity  arises 

3)  predicted  targets  do  not  materialize 

4)  predicted  targets  are  different  than  expected 

5)  predicted  targets  cannot  be  attacked  due  to  environmental 
conditions 

6)  status  of  weapon  delivery  platform  changes 

Since  the  first  trigger  is  somewhat  unspecific,  and  can  be  included  as  a 
general  case  of  the  four  triggers  that  follow,  trigger  two  was  used  to  provide 
specific  examples  in  the  storyboard.  The  sequence  of  screen  representations 
and  corresponding  descriptions  of  the  storyboard  design  are  presented  in 
Appendix  A.  A  sequence  of  decision  screens  to  decide  whether  to  retask  and 
divert  an  aircraft/weapon  and  attack  a  new  high  priority  target  is 
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considered.  First,  it  must  be  determined  whether  an  effective  weapon  for 
the  new  target  is  available  under  the  time  constraints;  then  the  trade-offs 
involved  in  retasking/diverting  must  be  considered;  the  FDO  must  also 
decide  how  the  target  that  results  from  retasking  the  weapon  assigned 
against  it  will  be  attacked. 


Evaluating  the  Design 

As  discussed  in  the  C  Evaluation  Workshop  Report  of  the  Military 
Operations  Research  Society  (MORS),  it  is  essential  to  begin  the  formulation 
and  application  of  measures  of  effectiveness  (MOEs)  during  the  early 
conceptual  phases  of  a  C  system: 

As  a  process,  the  formulation  of  MOEs  is  recursive  and  iterative  ....  the 
determination  of  shortfalls  in  MOEs  applied  to  a  system  is  fed  back 
into  the  conceptual  model  so  that  this  model  can  be  modified,  refined, 
or  changed.  Over  time,  the  MOEs  can  become  accurate  measures  of  an 
existing  system  or  can  be  modified  to  cope  with  the  evolutionary 
changes  in  the  system,  the  environment,  or  the  scenario.  (Sweet  and 
others,  1985  : 4-24). 


Based  on  this  guidance,  the  development  of  the  MOEs  should  begin  and 
evolve  along  lines  paralleling  the  system  development.  The  system  designer 
must  continuously  derive  conclusions  and  findings  from  applying  the  MOEs, 
and  judge  how  this  analysis  should  contribute  to  future  design  and 
implementation  decisions.  The  specific  analytical  MOES  for  the  retasking  DSS 
design  as  well  as  other  implementation  issues  are  discussed  in  Chapter  IV. 
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IV. 


To  fully  support  the  "start  small  and  grow"  objective  of  adaptive  DSS 
development,  it  is  necessary  to  merge  the  DSS  implementation  and 
evaluation  activities.  Evaluations  are  particularly  vital  during  all  phases  of 
the  adaptive  design  and  development  of  a  DSS.  This  is  true  for  two  primary 
reasons.  First,  the  benefits  of  the  adaptive  design  process  with  its  inherent 
flexibility  would  not  be  realized  if  the  ongoing  evaluations  were  not 
performed  to  determine  system  refinements;  early  evaluation  would  also 
prevent  the  possibility  of  initially  proceeding  down  the  wrong  path.  Second, 
without  regular  evaluation  during  the  entire  process,  the  adaptive  design 
would  begin  to  resemble  the  more  traditional  system  development  life  cycle 
in  which  initial  evaluations  are  performed  much  later  in  the  process,  often 
times  uncovering  user  dissatisfaction  too  late  to  remedy  the  problem. 

Fortunately,  an  early  evaluation  that  rates  a  prototype  design  for  a  DSS 
as  unsatisfactory  will  not  necessarily  hamper  further  development  of  the 
DSS;  instead  it  leads  to  an  improvement  in  the  general  problem  approach, 
or  necessary  refinements  in  the  design  process.  Recognizing  these  potential 
problems  early  facilitates  their  proper  correction  and  the  building  of  a  more 
valid  system  to  support  the  decision-making  process.  By  tackling  the 
problems  early,  there  is  no  need  later  to  apply  any  quick  fixes  to  portions  of 
the  system  that  do  not  meet  the  user's  needs  as  they  should.  On  the  other 
hand,  it  is  much  more  likely  that  a  poor  evaluation  phase  during  a 
traditional  system  life  cycle  approach  will  cause  considerable  consternation 
and  possibly  abandonment  of  the  system,  if  the  problems  detected  are 
thought  to  be  monumental  and  the  projects  funds  are  nearly  depleted. 
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,  Effectiveness.  Efficiency,  and  Reliability 


Because  of  the  importance  of  iterative  evaluation  during  the  adaptive 
design  of  DSS,  it  is  appropriate  to  evaluate  the  preliminary  storyboard  and 
kernel  design  for  the  retasking  DSS  for  the  ASOC.  This  calls  for  some  type  of 
evaluative  model  or  approach  to  be  used  during  this  phase  of  the  adaptive 
design  process.  In  general,  it  is  admittedly  difficult  to  formulate  objective 
measures  of  effectiveness  (MOE)  to  evaluate  a  specific  DSS  within  a  specific 
environment.  However,  several  current  researchers  working  in  the  area  of 
tactical  DSS  offer  some  specific  guidelines  for  evaluating  a  DSS  during  the 
design  phase. 

Samet  has  proposed  that  DSS  effectiveness  can  be  measured  at  the  design 
phase  by  "  1)  correct  assignment  of  functions  to  people  or  computer,  2) 
structural  complexity  (simple  is  better),  and  3)  correctness  of  algorithms  for 
their  stated  purpose"  (Riedel  and  Pitz,  1986  :  982-983).  Two  other 
evaluative  measures  that  Samet  describes  to  be  used  during  the  design 
phase  are  ( 1 )  efficiency  or  a  measure  of  the  number  of  user  steps  for  an 
operation,  and  (2)  reliability,  as  a  measure  of  the  effect  the  failure  of  one 


module  will  have  on  others. 


A  general  evaluation  of  the  retasking  DSS  can  be  started  using  several  of 
these  recommended  measurements.  Beginning  with  the  criteria  for 
effectiveness,  the  following  assessments  of  the  retasking  DSS  can  be  made. 
Table  I  summarizes  the  assignment  of  system  functions  to  either  the 
computer  or  the  user,  depending  on  their  strengths. 
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Table  I.  Assignment  of  DSS  Functions 
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Function 

Done  Bv 

Scan  database 

computer 

filter  out  bad  alternatives 

computer 

transit  time  calculation 

computer 

loiter  time  calculation 

computer 

weapon  recommendation 

computer 

reminder  of  priority  activities 

computer 

storing  decision  sequence 

computer 

input  criteria  for  database 

user 

establishing  constraints 

user 

choose  retasking  aircraft 

user 

choose  retasking  weapons 

user 

display  select  graphical  data 

user 

choose  decision  sequence 

user 

select  windows  displayed 

user 

Assignment  of  Functions.  The  assignment  of  functions  to  the  user  or  the 
computer  were  designed  using  knowledge  about  the  strong  and  weak  areas 
of  both  the  human  and  the  computer.  Rapid  scanning  of  the  database  to 
filter  out  inappropriate  user  options  and  the  quick  calculation  of  transit  and 
loiter  times  are  functions  assigned  to  the  system,  while  the  particular 
criteria  to  be  used  in  scanning  the  database  and  the  decision  of  what 
missions  or  aircraft  to  consider  for  retasking  is  left  up  to  the  decisionmaker. 
Most  importantly,  the  process  or  sequence  of  steps  to  be  used  in  making  the 
decision  are  left  up  to  the  user;  the  system  only  reminds  the  user  of  other 
high  priority  activities  that  must  be  managed. 

Structural  Complexity.  The  structural  complexity  of  the  system  should 
appear  rather  simple  and  easily  navigable  to  even  the  novice  user.  There 
was  a  deliberate  attempt  in  designing  the  DSS  to  give  the  user  as  much  or  as 
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little  complexity  as  he  desires  and  can  handle  during  the  decision  process. 
This  is  accomplished  through  the  use  of  a  common  work  area  where  clear 
pull-down  menus  are  accessible  and  the  user  can  open  multiple  decision 
windows  as  needed.  Models  (operations)  do  not  require  complicated 
procedures  for  inserting  input  data,  they  are  simply  selected  by  the  user, 
and  the  system  performs  the  insertion  into  the  operation  with  the 
highlighted  data  on  the  screen.  There  is  a  consistency  in  the  structure  of  the 
decision  windows  that  the  system  presents,  so  the  user  does  not  become 
uncomfortable  in  using  a  function  that  is  seldom  accessed.  The  design  allows 
the  addition  of  models  and  operations  without  making  the  DSS  appear 
additionally  complex  to  the  user. 

Correctness  of  Algorithms.  The  algorithm  for  making  the  retasking 
decisions  must  be  flexible,  depending  on  the  environment  constraints  input 
at  the  time.  Two  of  the  constraints  (time  and  weapons)  can  be  initially 
input  to  the  system  by  the  user,  to  determine  the  data  that  the  system  uses 
to  run  certain  models,  and  the  criteria  used  to  search  the  database.  The 
algorithm  is  not  fixed,  and  the  system  design  keeps  the  decision  process 
under  full  control  of  the  user,  and  as  variable  as  needed. 

Efficiency.  Efficiency  of  the  DSS  design  can  also  be  measured  by  the 
structural  consistency  and  relative  simplicity  of  the  system  in  the  user's 
eyes.  The  number  of  user  steps  needed  to  perform  an  operation  in  the 
retasking  DSS  is  generally  limited  to  two,  with  the  second  step  normally 
being  the  option  to  update  the  current  environmental  constraints  prior  to  the 
system  performing  an  operation,  or  running  a  model. 

Reliability,  or  ability  to  recover  from  failure,  of  the  DSS  is  also  an 
important  design  consideration,  although  it  comes  more  into  play  during  the 
actual  building  of  the  system.  The  current  DSS  design  permits  the  user  to 
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return  to  an  earlier  point  in  the  decision  process  if  an  error  or  failure  in  a 
system  module  is  detected.  Currently,  the  design  is  divided  into  three 
overall  system  modules.  One  is  the  module  that  interfaces  with  the  user 
through  screen  displays.  This  module  is  crucial  to  the  operation  of  the 
system;  its  failure  would  require  the  decisionmaker  to  revert  to  manual 
means.  There  is  no  alternate  method  to  access  data  and  models  except 
through  interface  with  the  system's  screen  displays.  The  accuracy  of  the 
system  recommendations  and  output  depend  on  the  currency  and 
correctness  of  the  second  module,  the  database.  Detected  inconsistencies  or 
failure  of  the  database  altogether  could  be  corrected  by  reloading  the 
system’s  database  through  its  interface  with  the  master  database,  or  a 
CAFMS-like  database  to  which  it  would  be  connected.  On  the  other  hand, 
the  reliability  of  the  model  portion  of  the  DSS  would  be  more  difficult  to 
insure.  The  best  way  to  guarantee  to  the  user  that  the  models  are  providing 
consistent  results  is  to  make  their  source  code  inaccessible  to  everyone 
except  the  model  manager,  or  other  appointed  individuals.  This  could  be 
accomplished  by  locking  the  model  code  in  secure  files,  to  which  there  was 
limited  access.  The  models  should  be  checked  at  routine  intervals  by 
personnel  intimately  familar  with  their  workings,  to  insure  they  are 
performing  as  expected,  and  to  make  any  necessary  changes  or  updates.  The 
users  should  be  informed  whenever  the  models  have  been  updated, 
especially  if  the  change  will  be  reflected  in  the  results  the  user  sees  during 
the  decision  process. 


Rouse  and  others  (Riedel  and  Pitz,  1986  :  983)  have  proposed  the 
additional  criteria  of  compatibility  and  understandability  to  analytically 


assess  the  DSS  during  the  design  phase.  Compatibility  refers  to  "the  degree 
to  which  the  demands  an  aid  places  on  users  sensory-motor  abilities  are 
within  the  limitations  of  the  user  population"  (Riedel  and  Pitz,  1986  :  983). 
Understandability  is  "the  extent  to  which  users  can  be  expected  to  have  the 
knowledge  required  to  understand  the  messages  displayed"  (Riedel  and  Pitz, 
1986  :  983).  Both  of  these  evaluative  criteria  seem  to  focus  on  the 
man-machine  interface  requirements.  Compatibility  of  the  DSS  design  was 
achieved  through  a  matching  of  the  typical  sensory-motor  skills  of  a  future 
retasking  DSS  user  with  those  skills  required  to  use  the  designed  DSS.  Many 
recommendations  were  taken  from  design  checklists  and  recent 
man-machine  interface  research.  Additional  inputs  were  made  by 
functional  area  experts  at  the  ASOC  at  Shaw  AFB  and  personnel  at  HQ  TAC. 
Understandability  was  achieved  by  formulating  the  system  messages  so  they 
are  straightforward  and  easily  understood  by  the  typical  DSS  user.  Of 
course,  what  is  meant  by  the  "typical  user”  is  predominantly  the  view  of  the 
DSS  designer  during  the  design  phase.  The  impression  that  this  designer  has 
of  the  typical  user  has  been  formed  by  minimal  interaction  with  a  limited 
number  of  potential  users  on  two  occasions.  This  impression  was  further 
molded  by  a  meeting  with  the  operational  requirements  experts  at  HQ  TAC, 
to  form  a  picture  of  the  generic  user  and  further  substantiate  general  user 
needs.  Unfortunately,  there  has  been  no  opportunity  for  regular, 
face-to-face  meetings  between  user(s)  and  designer  throughout  the  design 
phase,  to  further  clarify  design  issues  and  discuss  problems  as  they  arose. 
This  is  often  a  common  limitation  of  academic  research  projects,  unless  the 
potential  user  is  colocated  with  the  designer,  and  face-to-face 
communication  is  possible  on  regular  intervals.  This  limitation  has  impacted 
the  design  process  and  the  resulting  storyboard  to  a  certain  degree. 


primarily  in  the  area  of  the  amount  of  detail  that  was  incorporated  into  the 
design. 


Information 


All  of  the  previously  mentioned  evaluative  criteria  are  particularly 
important  for  focusing  on  the  user-DSS  (U/DSS)  interface  portion  of  the 
design.  However,  the  early  evaluative  process  during  the  DSS  design  phase 
should  also  consider  two  other  interfaces:  the  user-decisionmaking 
organization  (U/DMO)  interface,  and  the  decisionmaking 
organization-environment  (DMO/ENV)  interface  (Adelman,  1985  :  286-288; 
Riedel  and  Pitz,  1986  :  981).  Evaluation  of  the  DSS  from  the  U/DMO 
interface  level  would  include  such  questions  as: 


1)  How  well  does  the  user  with  his  DSS  fit  into  and 
support  the  larger  decision  making  cycles  of  the  ASOC 
and  the  Corps? 

2)  To  what  degree  does  use  of  the  DSS  contribute  to 
effective  decisionmaking  at  the  ASOC  and  Corps  level? 

3)  How  well  does  the  DSS  mesh  with  the  organizational 
climate,  the  constraints,  and  requirements  of  the 
ASOC  and  Corps? 


Each  of  the  above  evaluation  decisions  and  those  at  the  higher  DMO/ENV 

interface  level  appear  considerably  more  complex  and  difficult  to  quantify 

than  those  at  the  U/DSS  level;  perhaps  evaluations  at  these  two  upper  levels 

can  best  be  measured  during  actual  use  of  the  prototype  DSS  in  an 

operational  exercise.  In  fact,  Adelman  and  Donnell  propose  a  rigorous  plan 

to  be  used  to  evaluate  all  three  interfaces  (Adelman  and  Donnell,  1986  : 

285-309).  They  have  devised  a  lengthy  series  of  questions  for  users  and 
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specialists  to  evaluate  the  utility  of  DSS  prototypes.  Experimentally,  the 
questionnaire  was  found  to  be  "an  acceptable  instrument  for  measuring 
people's  subjective  assessment  of  DSS  prototypes"  (Adelman  and  others, 

1985  :  334-342).  This  research  is  important  because  it  is  aimed  at  learning 
the  distinct  ways  that  specialists  and  users  each  evaluate  a  DSS,  and  how 
these  differing  subjective  assessments  may  interfere  with  implementation  of 
the  DSS.  As  the  retasking  DSS  grows  and  a  working  prototype  is  developed, 
it  may  also  be  a  ripe  candidate  for  application  of  this  type  of  evaluation 
questionnaire  that  has  been  developed.  This  will  help  to  assess  whether 
potential  users  and  R&D  specialists  are  evaluating  the  DSS  similarly,  and 
how  this  will  impact  implementation. 

Ideally,  the  total  design  evaluation  should  provide  information  to 
decisionmakers  at  different  levels.  At  the  first  level  is  the  DSS  designer  who 
needs  information  for  design  decisions;  at  the  second  level  is  the  project 
manager  who  needs  information  for  project  decisions,  i.e.,  whether  to 
recommend  further  funding  for  continued  development;  at  the  third  level  is 
the  larger  tactical  research  organizations  who  may  be  able  to  use  the 
findings  of  the  current  DSS  evaluation  for  their  related  research  and 
development. 

Measures  of  Productivity.  Perception.  Process,  and  Product 

Sprague  and  Carlson  suggest  use  of  the  measures  of  (1)  productivity,  (2) 
perception,  (3)  process,  and  (4)  product  to  evaluate  the  impact  of  a  specific 
DSS  on  users,  the  organization,  and  the  environment  (Sprague  and  Carlson, 
1982).  The  following  discussion  outlines  a  plan  for  evaluating  an  operating 
prototype  of  the  retasking  DSS  later  in  the  development.  To  accomplish  such 
an  evaluation,  the  impact  of  the  DSS  on  four  critical  categories  should  be 


examined.  Using  this  evaluative  model,  the  potential  impact  of  the 
retasking  DSS  on  these  categories  is  examined  below: 


Impact  on  Decisions.  Impact  on  decisions  is  measured  by  looking  at 
DSS  productivity.  Included  in  this  group  are  measurements  of  the  time  and 
cost  in  reaching  a  decision  and  the  results  of  the  decision.  The  following 
suggested  measures  are  appropriate  within  this  category: 

1)  Measurement  of  the  difference  in  requested  Time  On 
Target  and  actual  Time  On  Target  with  and  without 
use  of  the  DSS; 

2)  Measurement  of  time  needed  to  execute  mission  (time 
difference  between  arrival  of  the  request  and  the  time 
that  the  aircraft  launch  order/controlling  data  is 
passed)  with  and  without  use  of  the  DSS; 

3)  Measurement  of  the  actual  effect  of  weapon  on  target 
and  comparison  with  desired  effect,  with  and  without 
use  of  the  DSS; 

4)  Measurement  of  the  number  of  sorties  required  to 
achieve  the  desired  effect  on  the  target  with  and 
without  use  of  the  DSS; 

5)  Measurement  of  the  effect  of  a  retasked  mission  on 
the  Army  initiatives  it  supports;  did  the  retasking 
contribute  to  a  significant  Army  breakthrough? 


Impact  On  Decisionmaker.  This  impact  is  measured  by  looking  at  the 
user’s  perception.  These  measures  center  around  the  affinity  the  user  feels 
for  the  DSS,  and  the  trust  and  confidence  that  he  has  in  the  system.  The  two 
techniques  that  may  work  well  in  this  category  are  attitude  surveys  and 
cognitive  testing  to  get  at  the  real  preferences  of  the  user.  Attitude  surveys 
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are  difficult  to  construct  to  get  the  greatest  benefit  from  them,  and  cognitive 
testing  is  still  a  very  new  concept  and  still  under  development  (Sprague  and 
Carlson,  1982  :  161-164),  Some  other  practical  measures  that  may  work 
include: 

1)  Measuring  the  amount  of  time  the  user  is  actively  using  the  DSS; 

2)  Measuring  the  percent  of  time  the  user  actually  implements  the 
decision  he  arrived  at  through  use  of  the  DSS,  without 
reconfirming  the  decision  through  other  means; 

3)  Measurement  of  the  satisfaction  of  the  supported  Army  unit  with 
the  response  and  effectiveness  of  retasked  sorties; 

4)  Measurement  of  the  number  of  new  and  creative  decisions  that 
result  through  use  of  the  DSS  that  were  previously  not  considered 
without  use  of  the  DSS; 

5)  Measurement  of  frustration  level  that  user  reaches  when  using 
the  DSS  versus  the  frustration  level  without  use  of  the  DSS; 
frustration  level  may  be  measurable  in  a  user  questionnaire. 

Impact  on  Decisionmaking.  This  impact  is  measured  by  looking  at  the 
decision  process.  Here,  different  variables  of  the  decision  process  are 
examined:  the  number  of  alternatives  and  participants,  and  different  time 
measurements  of  the  process  are  considererd.  Measurements  that  could  be 
taken  to  evaluate  the  DSS  in  this  category  include: 

1)  Measurement  of  the  amount  of  time  spent  on  different  decision 
activities  with  and  without  use  of  the  DSS; 

2)  Measurement  of  the  number  of  alternative  aircraft/ordnance 
combinations  and  possible  weapons  that  could  be  used  against  a 
target; 


3)  Measurement  of  the  amount  of  time  DSS  is  used  by  FDO  and  other 
personnel  in  the  ASOC; 

4)  Measurement  of  the  different  views  of  the  data  of 
weapons/targets/geographic  map  that  the  user  generates  in 
reaching  the  decision; 

5)  Measurement  of  different  stages  the  user  is  in  along  the  decision 
timeline  with  and  without  use  of  the  DSS. 

Technical  Merits.  The  technical  merits  are  measured  by  looking  at  the 
technical  aspects  of  the  product.  These  measures  revolve  around  the 
different  costs  (development/operating/maintenance)  associated  with  the 
system.  Measurement  of  costs  during  the  early  design  and  implementation 
phases  of  a  DSS  should  be  considered  similar  to  Research  and  Development 
(R&D)  costs,  which  may  appear  high  for  the  product  performance.  However, 
if  they  were  considered  as  operational  or  maintenance  costs,  they  may  be 
unacceptably  high,  which  may  reflect  unfavorably  on  the  DSS  program. 
Education  costs  may  also  be  high  with  a  system  like  this,  especially  if  a 
central  prototyping  and  training  facility  is  established. 

Other  Evaluation  Methods 

It  is  also  suggested  that  elements  of  the  external  environment  are 
important  target  systems  during  evaluation.  Perhaps  the  best  external 
"customer"  to  examine  with  the  retasking  DSS  is  the  Army  unit  that  receives 
the  air  support.  Some  type  of  evaluation  of  the  effect  on  their  small  portion 
of  the  Airland  Battle  may  be  appropriate.  A  general  attitude  survey  of 
Army  personnel  may  also  uncover  a  change  in  attitude  with  the  use  of  the 
DSS. 

Whatever  method  is  used,  evaluation  will  be  difficult  because  of  the 
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everchanging  and  unpredictable  tactical  environment.  A  controlled  study 
conducted  during  an  exercise  in  which  two  groups  of  FDOs  receive  the  same 
inputs,  with  only  one  group  able  to  respond  using  the  DSS,  may  also  prove 
to  be  a  valid  evaluation  tool. 

In  addition  to  evaluative  criteria,  the  following  guidelines  on  DSS 
generators  are  provided  for  implementating  the  prototype. 

DSS  Generators 

After  design  and  evaluation  of  the  preliminary  storyboard,  it  is 
appropriate  to  execute  the  plan  for  building  the  DSS  kernel,  either  by 
designing  and  writing  the  system  software  from  scratch  or  using  a  DSS 
generator,  or  more  likely  through  a  combinination  of  generator  tools  and 
software  written  in-house.  A  DSS  software  generator  can  be  defined  as  a 
software  package  (either  off-the-shelf  or  developed  in-house)  used  to 
develop  a  specific  DSS.  Sprague  and  Carlson  point  out  that  because  there 
currently  are  no  well-integrated  packages  of  tools  or  DSS  generators,  that 
the  development  will  most  likely  be  a  "combination  of  software  purchase 
and  internal  development  to  integrate  and  fill  in  the  gaps"  (Sprague  and 
Carlson,  1982  :  63). 

To  establish  a  framework  for  building  the  DSS  and  specifying  the  DSS 
generator  requirements,  the  following  four  step,  top-down  analysis  is 
recommended  by  Sprague  and  Carlson: 

1)  Identify  Overall  Objectives.  This  category  is  very 
general  and  focuses  on  the  decision-making  system, 
consisting  of  the  user,  with  a  task  in  an  organizational 
setting  and  using  a  specific  DSS.  The  generator  should 
be  able  to  be  used  to  build  a  specific  DSS  that  0) 
supports  all  phases  of  the  decision-making  process,  (2) 
supports  a  variety  of  decisionmaking  processes  or 
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cognitive  styles,  and  (3)  is  easy  to  use.  The  generator  ; 

should  also  be  flexible  enough  to  facilitate  the  iterative  | 

design  process  that  characterizes  development  of  the 

DSS.  Another  important  requirement  of  the  generator  ! 

is  to  support  communication  between  the  user  and  the  ■ 

builder;  communication  that  is  necessary  for 
enhancing  and  refining  the  DSS  as  it  grows. 

2)  Identify  General  Capabilities.  These  flow  naturally 
from  the  overall  objectives  and  include  the  following 
three  capabilities:  (1)  the  generator  should  be  easy  for 
the  DSS  builder/user  to  use,  (2)  the  generator  should 
provide  access  to  a  wide  variety  of  data  sources  that 
supports  problem-solving  and  decisionmaking 
activities,  and  (3)  the  generator  should  provide  access 
to  analysis  capabilities. 

3)  Specific  Capabilities.  This  category  includes  the  specific 
capabilities  that  support  the  general  ones.  For 
instance,  an  integrated  DBMS  as  part  of  the  generator 
would  satisfy  the  general  capability  of  accessing  a  wide 
variety  of  data  and  then  using  the  data  in 
conjunction  with  the  other  components  of  the  DSS. 

4)  Specific  Features.  This  category  includes  specific 
features  needed  to  implement  the  specific  capabilities. 

For  example,  one  of  the  features  needed  to  maintain  a 
database  would  be  the  feature  that  would  allow  the 
creation  of  new  relations.  Another  example  of  a 
feature  would  be  the  capability  to  write  unique 
mathematical  equations  that  could  be  used  in  model 
development. 


Selecting  a  Generator.  What  Sprague  and  Carlson  infer  with  the  above 
framework,  and  what  other  researchers  claim  is  needed  in  choosing  the 
right  DSS  generator  is  "a  thorough  and  systematic  selection  process" 
(Reimann  and  Waren,  1985  :  167).  The  point  that  most  of  these  researchers 
also  make  is  that  the  evaluation  criteria  for  selecting  the  generator  should 
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emphasize  end-user  needs  because  of  the  key  role  of  the  user  in  the  DSS 
growth  process.  A  complete  and  detailed  checklist  of  key  user-oriented 
characteristics  available  in  DSS  generator  packages  is  presented  by  Reimann 
and  Waren  (Reimann  and  Waren,  1985  :  168).  This  comprehensive  list 
should  be  used  carefully  in  comparing  DSS  generators;  simply  counting 
features  can  ignore  the  underlying  structure  of  the  DSS  and  its  potential  for 
growth  and  expansion.  Using  these  criteria  to  evaluate  and  choose  a 
generator  would  be  an  appropriate  thesis  in  itself. 

The  capability  to  grow  and  expand  is  one  of  the  overall  core  requirements 
needed  during  the  adaptive  design  process.  The  potential  generator  should 
be  equipped  with  sophisticated  graphics  capabilities  for  the  user  and 
designer  to  generate  the  initial  storyboard.  After  designing  the  screens  of 
the  storyboard,  there  is  a  need  to  tie  them  together  logically  to  demonstrate 
the  different  potential  sequences  of  screen  displays  that  are  possible  during 
the  decision  process.  Rouse  suggests  a  "part-task  simulator"  to  simulate  the 
DSS  in  appearance,  static  and  dynamic  characteristics,  and  range  of 
decision-maker  activities  (Rouse,  1986  :  279).  After  the  initial  design  is 
demonstrated  and  accepted,  the  supporting  database  and  model  base  must 
be  created  with  the  generator  tools.  These  two  capabilities  of  the  generator 
should  especially  be  examined  for  growth  potential,  since  the  database  and 
model  base  are  generally  the  two  portions  of  the  DSS  that  will  expand  the 
most.  Ideally,  the  generator  should  be  structured  to  be  operated  by  both 
the  novice  user  and  expert  programmer  alike,  with  on-line  help  messages 
and  full-screen  entry  and  editing  of  input  with  appropriate  prompt  or  menu 
formats,  if  needed.  The  generator  should  be  equally  strong  in  the  ability  to 
document  the  growing  DSS  both  through  automatic  documentation  features 
and  user-selected  ones. 
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This  chapter  provided  many  of  the  crucial  implementation  issues  in 
building  and  evaluating  the  specific  retasking  DSS.  Chapter  V  critiques  the 
major  techniques  of  the  adaptive  design  methodology  and  discusses  how  it 
has  supported  growth  of  the  retasking  DSS  so  far.  Additional 
recommendations  for  the  continuation  of  this  project  are  also  provided. 


V. 


I 


$ 

SI 


8 


£ 


1 

§ 

s 

;* 

.N 

.N 

e 

2 

v! 


,y 


i 

*▼*, 


Conclusions.  Recommendations,  and  Enhancements 

Where  Adaptive  Design  Has  Led 

If  adaptive  design  is  partially  characterized  by  the  phrase  "start  small 
and  grow"  (Valusek,  1987:2),  then  it  is  appropriate  to  say  this  design 
approach  has  facilitated  the  building  of  a  small  basic  framework  from  which 
the  retasking  DSS  for  the  ASOC  can  root  itself  and  grow.  However,  it  is 
naive  to  think  the  process  can  be  successfully  continued  without  the  support 
of  some  strict  organizational  structures  and  mechanisms.  A  good  approach 
to  adaptive  design  is  not  necessarily  any  less  structured  than  the  traditional 
life-cycle  approach.  The  fact  that  adaptive  design  appears  less  structured  to 
those  unfamiliar  with  and  unpracticed  in  the  approach  is  due  to  the  lack  of 
documentation  that  exists  to  explain  how  the  approach  has  been  applied. 

One  of  the  goals  of  research  and  development  such  as  this  project,  is  to 
derive  a  recommended  approach  which  includes  design  activities  and  some 
sort  of  schedule  or  scheme  for  applying  the  activities.  The  following  sections 
encapsulate  the  accomplishments  of  each  of  the  following  recommended 
adaptive  design  modules.  Further  discussion  on  what  supporting 
organizational  mechanisms  are  needed  to  nurture  the  DSSs  growth  is  also 
included.  The  particular  facilitators  and  hindrances  to  adaptive  design 
during  this  project  are  also  examined. 

Concept  Mapping  Growth.  Concept  mapping  as  a  method  of 
uncovering  and  refining  the  decision  process  should  not  be  limited 
to  the  early  phases  of  the  system  growth;  it  should  be  continued  throughout 
the  life  of  thr  retasking  DSS.  As  the  decision  processes  which  the  system  is 
based  on  change  and  grow  within  the  operational  environment,  concept 
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mapping  will  help  to  translate  the  changes  to  the  DSS.  If  this  growth  of  the 
concept  maps  is  continued  throughout  the  life  of  the  system,  the  maps  will 
serve  as  useful  supporting  documentation  both  for  the  user  and  the  builder. 

If  maintained,  the  concept  maps  should  correspond  closely  with  the 
evolving  system.  They  are  a  portion  of  the  system  that  the  user  would  be 
capable  of  and  may  even  enjoy  maintaining;  they  graphically  reflect  the 
user's  knowledge  and  understanding  of  the  retasking  decisions,  and  most 
likely  the  user  would  want  them  to  reveal  his  most  detailed  understanding 
of  the  decisions  involved.  Additionally,  concept  maps  of  various  users  of  the 
DSS  can  be  made  available  for  the  exchange  of  information  and 
understanding  of  the  decision  process.  Users  should  be  able  to  further 
enhance  their  own  understanding  through  the  maintenance  and  exchange  of 
concept  maps. 

The  specific  concept  maps  used  as  a  starting  point  for  the  retasking  DSS 
also  need  to  be  refined  as  the  DSS  develops.  Limited  opportunity  to  meet 
with  operational  experts  and  potential  users  during  this  project  restricted 
the  creation  of  extensive  maps.  Although  the  DSS  is  designed  to  support  the 
Army  in  the  Airland  Battle,  only  one  Army  artillery  expert  participated  by 
creating  a  concept  map.  There  are  still  numerous  ideas  about  the  retasking 
decisions,  especially  in  the  areas  of  (1)  BAI  missions  and  (2)  diverting  CAS 
resources  to  a  BAI  mission,  that  could  be  revealed  through  the 
development  of  further  maps  with  both  Air  Force  and  Army  personnel. 

Kernel  Selection  and  Growth.  Through  a  combination  of  (1)  ideas 
from  concept  maps,  (2)  ideas  generated  during  dialogue  with  experts,  and 
(3)  user  reactions  to  draft  storyboards,  the  kernel  of  the  retasking  DSS  was 
initiated.  Although  some  of  the  design  (Ground  Map  portion)  is  based  on  a 
particular  theater  scenario  for  the  sake  of  demonstration,  the  kernel  design 


is  essentially  generic.  If  the  DSS  design  were  to  become  too  theater  specific 
during  the  early  phases,  it  might  easily  be  rejected  by  other  theaters  as 
inappropriate  for  their  needs.  Some  of  the  basic  battle  strategies  and 
operational  concepts  do  vary  significandy  from  theater  to  theater;  however, 
there  has  been  an  attempt  in  the  kernel  design  to  avoid  focusing  on  these 
unique  aspects.  The  advantage  of  a  properly  chosen  kernel  in  this  case  is  its 
applicability  to  different  theaters  with  diverse  operations.  The  flexibility 
designed  both  into  the  structure  and  operation  of  the  kernel  DSS  supports 
this.  Of  course,  this  generic  design  is  especially  beneficial  to  the  Conus 
ASOCs,  who  could  deploy  to  a  variety  of  locations,  each  with  a  slightly 
different  mode  of  operation.  It  may  in  fact  be  useful  to  develop  a  series  of 
"shells"  to  be  used  for  deployments  to  different  locations.  The  shell  would 
set  up  the  system  for  its  customized  use  in  a  particular  environment.  It  may 
(1)  alter  parameters  in  models  slightly,  (2)  modify  or  create  different  data 
base  relations,  (3)  vary  the  sequence  of  possible  screen  representations, 
and  (4)  permit  the  interface  with  other  tactical  systems.  Any  alterations  to 
the  DSS  caused  by  the  shell  would  be  intended  to  make  the  user  as 
comfortable  as  possible  within  the  particular  environment  he  is  operating. 

Feature  Chart  Growth.  The  feature  chart  is  another  important  part  of 
the  system  that  both  simplifies  communication  between  decisionmaker, 
analyst  and  system  designer/builder  (Seagle  and  Belardo,  1986  :  19),  and 
serves  as  especially  useful  documentation  while  the  DSS  is  evolving.  If  all 
three  individuals  work  from  the  same  or  similar  feature  charts,  there  is 
much  less  of  a  chance  for  misunderstanding.  The  feature  chart  represents 
the  system  as  seen  through  the  eyes  of  the  decisionmaker,  and  insures  that 
the  decisionmaker  and  analyst/builder  have  a  common  understanding  of  the 
system  linkages,  and  the  interactions  involved  in  it.  The  feature  chart  does 


not  suffer  from  the  complexity  and  abstract  nature  of  more  traditional 
analysis  and  system  structure  diagrams  that  analysts  and  builders  have  used 
exclusively.  Feature  charting  serves  the  analyst,  builder,  and  user  equally 
well. 

A  modified  feature  chart  is  used  in  the  retasking  DSS  to  guide  the  user 
through  the  storyboard.  Below  each  screen  representation  in  the  storyboard 
is  a  miniature  feature  chart  with  the  portion  of  the  feature  chart  highlighted 
that  corresponds  to  the  screen  design  above  it.  As  the  DSS  grows,  it  is 
essential  to  update  the  hierarchy  of  feature  charts  in  step  with  the  evolving 
DSS,  to  assist  in  the  communication  between  the  user,  the  analyst,  and  the 
builder.  Updating  the  feature  chart  can  be  easily  accomplished  by  the 
designer  or  analyst  working  with  the  user.  The  software  that  is  chosen  for 
the  user  to  keep  the  storyboard  updated  should  also  allow  update  of  the 
feature  chart.  This  way  he  is  able  to  maintain  a  current  storyboard  set  and 
the  supporting  documentation  provided  by  the  feature  chart. 

Storyboard  Growth.  The  storyboard  is  a  critical  part  of  the  adaptive 
design  approach  that  begins  in  the  early  design  phase  and  continues 
throughout  the  life  of  the  DSS.  It  is  critical  for  two  reasons.  First,  it 
represents  the  key  link  that  integrates  the  user  both  into  the  design  process 
and  the  system  growth  or  evolution.  Secondly,  the  storyboard  serves  as  the 
crucial  tool  to  help  the  DSS  evolve  with  the  evolving  user  needs.  With  the 
sophisticated  and  easy-to-use  graphics  software  that  is  available  today, 
users  should  have  little  difficulty  creating  new  screens  and  refining  old  ones. 
To  be  most  effective,  the  operational  DSS  should  have  this  graphics  design 
software  capability  built-in.  Since  most  ideas  for  DSS  enhancement  and 
growth  will  come  to  the  user  while  he  is  using  the  DSS.  there  must  be 
support  for  allowing  the  user  to  experiment  with  new  ideas.  One  method 
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that  would  work  is  the  ability  to  quickly  produce  an  annotated  copy  of  a 
current  screen  representation  during  the  decision  process  for  later 
examination.  The  decisionmaker  may  be  having  difficulty  with  a  particular 
display  format.  In  his  opinion,  there  may  be  critical  information  missing  or  a 
restriction  in  what  data  or  models  are  accessible.  Perhaps  the  senes  of  steps 
necessary  for  a  certain  decision  process  is  clumsy,  or  distracts  the  user  and 
prevents  him  from  using  the  display  as  intended.  With  many  of  these 
potential  DSS  flaws,  the  problem  may  be  subtle  and  forgotten  shortly  after  it 
is  encountered,  unless  the  user  can  produce  a  copy  of  the  deficient  display 
on  the  spot  to  trigger  his  memory  at  a  later  time.  This  DSS  capability  would 


complement  the  hookbook  capability.  Ideally,  the  user  would  be  able  to 
easily  link  his  hookbook  entries  with  the  corresponding  annotated  copy  of 
the  screen  display  for  better  clarity  and  recall. 

Users  of  the  DSS  should  be  encouraged  to  satisfy  their  evolving  decision 
needs  by  creating  and  relining  the  storyboard.  This  evolving  storyboard 
becomes  a  dynamic  statement  of  requirements.  The  advantage  to  having 
the  user  maintain  it  is  that  it  never  becomes  outdated,  and  remains  several 
steps  ahead  of  the  operational  DSS.  In  addition,  the  evolving  DSS  is  always 
moving  in  the  direction  of  better  satisfying  the  users  needs.  This  researcher 
believes  that  many  users  will  savor  their  role  in  the  evolving  DSS  as 
storyboard  designers,  and  will  take  their  storyboard  development 
responsibility  seriously.  The  key  though,  is  to  provide  a  mechanism  that 
will  allow  them  to  quickly  accomplish  this,  without  having  to  do  alot  of 
writing,  or  struggling  with  foreign  software.  In  effect,  the  user  is  coaxed 
into  generating  his  decision  needs  within  the  environment  he  is  most 
comfortable  and  familiar.  The  results  should  be  more  thorough  and 


generated  during  the  actual  decision  process. 

Although  the  initial  Retasking  storyboard  set  was  designed  by  this 
researcher,  further  storyboard  maintenance  and  refinement  should  be 
turned  over  to  the  operational  users  as  soon  as  possible.  The  diversity  of 
ideas  that  could  be  generated  at  this  early  stage  of  the  DSS  development 
through  the  direct  user's  involvement  would  improve  the  evolving  DSS 
kernels.  The  difficulty  that  exists  is  how  to  manage  the  evolving  storyboards 
from  all  the  user  locations  until  the  requirements  can  be  incorporated  into 
the  operational  DSS.  A  proposed  organizational  solution  is  offered  later  in 
this  chapter. 

Hookbook  Growth.  The  hookbook  is  a  readily  accessible  method  of 
recording  ideas  for  DSS  enhancement.  This  purpose  ties  it  closely  to  the 
storyboard  enhancement  method.  During  design  of  the  retasking  DSS.  this 
researcher  used  the  method  suggested  by  Valusek  (Valusek,  1987: 1 1 ).  This 
manual  method  of  recording  an  idea  for  enhancing  the  DSS,  with  the  date 
and  circumstance  under  which  it  occurred  seemed  to  work  better  as  the 
project  progressed.  Its  success  depended  on  (1 )  the  accessibility  of  small 
notecards  when  the  idea  occurred  and  (2)  the  discipline  to  write  down  the 
idea  concisely  and  as  soon  as  possible.  This  method  resulted  in  a  modest 
number  of  notecards  near  the  end  of  the  design  phase.  The  majority  of  the 
cards  were  produced  in  the  latter  half  of  the  project  period,  when  the 
practice  became  more  ingrained  and  the  frequency  of  concrete  ideas  coming 
to  mind  seemed  to  increase.  It  seems  natural  that  the  frequency  of  ideas 
should  increase  with  increasing  array  of  storyboards  and  designs  to 
stimulate  new  ideas. 

To  combine  the  effects  of  the  developing  storyboards  and  hookbook  ideas, 
it  would  be  helpful  to  be  able  to  link  the  two  within  the  operational  DSS 


software.  The  user  should  be  given  the  capability  to  link  the  hookbook  ideas 
together  among  themselves  and  with  the  storyboards  for  future  perusal  and 
maintenance.  He  should  also  be  able  to  easily  vary  the  sequence  of  display 
of  these  linked  documents.  This  flexibility  will  allow  the  user  to  view  the 
ideas  in  a  variety  of  sequences  and  categories;  this  variety  should  encourage 
the  formulation  of  further  ideas  by  providing  the  freedom  to  look  at  the 
ideas  already  generated  in  a  new  perspective  (Valusek,  1987:1 1). 

TM 

HyperCard  is  one  example  of  off-the-shelf  software  that  provides  this 
capability  to  create  idea  notecards  and  then  link  them  in  a  variety  of  ways. 

Growth  of  the  Retasking  DSS 

The  methods  described  in  the  preceding  sections  provide  the  means  for 
the  user  to  support  the  DSSs  incremental  growth.  One  idea  with  potential  for 
further  development  that  was  generated  during  the  initial  design  phase 
involves  support  for  extended  range  and  more  complex  CAS  mission 
planning.  With  this  enhancement,  the  DSS  would  be  able  to  support 
situations  in  which  tactical  air  to  support  land  force  units  operating  beyond 
the  Forward  Line  of  Own  Troops  (FLOT)  will  be  needed.  Retasking  for  this 
type  of  operation  parallels  that  of  BAI,  but  Final  attack  control  will  follow 
CAS  procedures,  and  may  require  special  force  packaging.  Retasking  for  this 
type  of  mission  would  be  more  complex  than  retasking  CAS  missions  for  the 
FLOT  area.  First,  the  distances  that  aircraft  would  have  to  fly  to  reach  a 
new  target  area  beyond  the  FLOT  would  generally  be  greater.  Certain 
aircraft,  i.e.,  A- 10s  might  be  unsuitable  for  these  extended  missions;  the 
DSS  would  have  to  support  selection  of  proper  aircraft/weapon  for  a  mission 
of  this  sort.  The  possibility  of  using  aircraft  planned  for  BAI  missions  would 
be  much  greater  with  an  extended  CAS  mission  requirement;  the  DSS  would 
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have  to  support  integrated  CAS/B AI  retasking  to  a  much  greater  degree. 

'J 

Command,  Control,  and  Communication  (C  )  procedures  with  CAS  aircraft 
beyond  the  FLOT  would  be  different  than  with  CAS  aircraft  behind  the  FLOT; 
the  DSS  would  have  to  operate  effectively  using  information  from  these 
alternate  procedures.  The  threat  environment  for  aircraft  operating  beyond 
the  FLOT  would  also  be  different;  more  specific  support  for  transiting 
aircraft  through  these  high  threat  areas  would  be  needed,  as  well  as  any 
control  or  orbit  points  along  the  way. 

Other  Enhancements.  The  list  of  DSS  capability  enhancements  does  not 
stop  here.  Additional  ideas  are  included  in  Appendix  B.  Ideas  in  the 
appendix  were  derived  from  concept  maps  and  storyboards,  inputs  from 
users,  and  possible  mission  scenarios  presented  in  official  joint  operation 
manuals.  These  ideas  seem  to  be  several  of  the  major  enhancements  that 
will  require  smart  integration  of  the  mechanisms  for  the  evolving  DSS.  They 
are  certainly  not  enhancements  that  the  DSS  builder  will  be  able  to  simply 
add  without  comprehensive  storyboard  input  from  the  users. 

Plan  for  DSS  Growth 

The  plan  for  the  growth  of  the  retasking  DSS  must  be  well  thought  out, 
and  should  proceed  using  all  the  mechanisms  of  adaptive  design.  The 
current  effort  for  upgrade  of  the  ASOC  is  focusing  on  a  modular  approach  to 
hardware  integration.  It  is  believed  that  considerable  technology  transfer 
from  related  applications,  and  off-the-shelf  hardware  and  software  will 
satisfy  the  needs  of  the  ASOC  of  the  future.  Although  these  beliefs  about 
modularity  appear  valid  at  this  time,  there  remains  a  gap  in  the  early 
design  phases  so  far.  That  gap  is  the  lack  of  an  adaptive  design  structure 
that  will  lead  the  development  of  an  ASOC  DSS  based  on  the  important  role 
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and  stimulus  of  the  decisionmaker  throughout  the  life  of  the  DSS.  As  Boar 
warns:  complete  "definition  of  the  system  occurs  through  gradual  and 
evolutionary  discovery  as  opposed  to  omniscent  foresight"  (Boar,  1984  :  5). 
The  following  organizational  structures  are  required  to  support  the  gradual 
learning  about  and  incremental  development  of  the  retasking  DSS. 

Organizational  Requirements.  Specific  organizational  requirements  exist 
at  several  levels.  Within  the  CONUS,  there  is  the  user  level  at  the  ASOCs  at 
Shaw  AFB  and  Bergstrom  AFB.  Prototypical  models  of  the  DSS  must  be 
installed  at  these  two  sites  as  soon  as  they  are  available.  In  the  meantime, 
users  at  these  locations  must  be  given  the  means  to  explore  requirements 
through  the  Storyboard  and  hookbook  mechanisms  as  described.  Each  of  the 
sites  should  have  a  representative  to  coordinate  and  encourage  this  effort. 

He  should  be  well  versed  or  taught  about  the  adaptive  design  process,  and 
the  importance  of  his  or  his  replacement's  role  throughout  the  life  of  the 
system.  With  the  problem  of  assignment  transfers,  it  would  be  best  to  have 
two  individuals  at  this  level  knowledgeable  about  and  co-managing  this 
effort. 

At  the  next  level,  TAC/DR  should  be  responsible  for  the  critical  job  of 
integrating  the  storyboard  and  hookbook  requirements  that  are  generated  at 
the  ASOC  level,  and  formulating  the  ongoing  plan  for  implementation  of  this 
gradual  growth.  TAC/DR  should  insure  that  ASOC  users  are  thoroughly 
trained  in  the  adaptive  design  process  and  in  use  of  the  design  tools 
incorporated  in  the  DSS.  Valusek,  in  his  paper  on  adaptive  design  has 
suggested  the  establishment  of  a  DSS  "referree"  and  two  assisting 
individuals,  the  Data  Administrator  (DA)  and  the  Model  Administrator  ( MA ) 
(Valusek,  1987:12).  The  referee  is  perhaps  a  user  expert  with  systems 
knowledge  who  is  quite  high  in  the  organization,  and  will  not  be  bogged 
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down  by  political  roadblocks.  He  is  responsible  for  validating  and 
prioritizing  user  generated  design  requirements,  and  resolving  any  conflicts 
that  arise.  The  DA  and  MA  also  interface  with  the  user  at  the  ASOCs  and 
insure  the  integrity  of  the  data  and  models  used  in  the  DSS.  This  researcher 
believes  the  .e  three  individuals  are  critical  at  this  level.  They  are  required 
to  coordinate  the  inputs  from  the  users  and  also  serve  as  a  liaison  between 
the  users  and  the  prototyping  facility.  The  DA  and  MA  are  needed  to 
manage  the  different  data  and  model  requirements  for  the  different 
theaters. 

TAC/DR  should  have  the  additional  responsibility  of  managing  the 
incremental  building  and  testing  of  the  operational  DSS  at  the  TAC 
prototyping  facility.  In  this  role,  they  are  responsible  for  bringing  together 
user,  builder,  technical  experts/consultants,  and  outside  contractors.  The 
timing  for  these  meetings  and  tests  is  perhaps  best  gauged  by  closely 
managing  the  incremental  growth  of  the  DSS.  and  anticipating  when  the 
assembly  of  different  players  will  most  benefit  the  adaptive  process.  One  of 
the  first  appropriate  times  for  an  assembly  would  be  after  implementation 
of  the  initial  kernel,  to  investigate  the  design  of  additional  kernels  and 
evaluate  the  success  of  the  first. 

The  technical  work  of  Rome  Air  Development  Center  (RADO  and  project 
management  of  Electronic  Systems  Division  (ESD)  for  the  ASOC  DSS  needs 
be  more  closely  integrated  with  the  adaptive  design  at  TAC  and  the  ASOCs 
Part  of  this  integration  will  be  provided  by  interaction  and  exchange  of  ideas 
at  the  prototyping  facilities.  An  improved  integrated  approach  to  the  DSS 
growth  could  be  realized  if  RADC  and  ESD  modified  their  modular  growth 
philosophy  to  include  the  adaptive  design  techniques.  The  success  of 
TAC/DR  in  organizationally  supporting  and  using  adaptive  design  may 


heavily  influence  the  response  of  RADC  and  ESD. 


As  the  DSS  is  created  and  begins  to  grow,  it  is  essential  that  a  plan  and 
supporting  materials  be  developed  as  a  manual  backup  to  the  system.  It  is 
likely  that  the  expected  tactical  environment  communication  outages  will 
sever  the  ASOC  from  the  TACC  and  other  agencies  that  provide  real-time 


data  links  with  master  databases.  The  current  manual  system  status  boards 


used  by  the  CONUS  ASOC  at  Shaw  AFB  (682  ASOC)  to  maintain  status  of  the 


battle  and  make  their  decisions  include: 


1 )  CAS  Mission  Status  Board 


2)  RECCE  Mission  Status  Board 


3)  FAC  Mission  Status  Board 


4)  Geographic  Wall  Map 


5)  Weather  Status  Board 


6)  Radio  Circuit  Status  Board 


7)  TACP  Status  Board 


8)  Standard  Conventional  Load(SCL)  Board 


9)  Unit  Call  Sign  Board 


It  would  only  be  necessary  to  revert  to  use  of  these  manual  boards  if  the 


retasking  DSS  failed  or  the  overall  ASOC  system  lacked  sufficient 


redundency.  However,  decisionmakers  would  resist  using  the  masking  DSS 
if  they  knew  that  no  reliable  backup  system  existed.  Consequently,  a 
portion  of  the  design  includes  the  backup  information  that  would  be 


generated  by  the  retasking  DSS  to  support  the  decisionmaking  during  DSS 
downtime.  At  regular  intervals  the  system  should  produce  a  hardcopy  of 


to 
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the  information  exactly  as  it  would  appear  on  the  manual  boards.  The 
frequency  of  producing  the  hardcopy  information  should  vary  depending  on 
the  level  of  current  activity  and  the  amount  of  decision-relevant  information 
generated.  The  DSS  should  monitor  this  level  of  activity  automatically  and 


adjust  the  frequency  of  hardcopy  printout  as  needed.  Producing  the 
hardcopy  in  the  status  board  format  would  allow  the  information  to  be  easily 
transferred  to  the  boards  if  the  back-up  system  went  into  effect.  It  would 
also  be  necessary  to  produce  hardcopy  overlays  of  the  geographic  map 
displays  with  key  symbology  shown.  These  would  be  used  as  overlays  on 
the  geographic  wall  map  if  decisions  had  to  be  made  using  the  manual 
system.  Additionally,  under  a  weapon  constrained  scenario,  a  hardcopy  of 
adjacent  Corps  assets  would  also  be  needed  to  aid  in  the  retasking  process. 

The  DSS  should  automatically  include  all  hardcopy  printouts  needed  for  the 
manual  decisionmaking  process  under  any  constrained  situations  that  they 
are  currently  operating. 

What  Facilitates  and  Hinders  Adaptive  Design 

Discussion  of  what  helped  and  hindered  adaptive  design  of  the  retasking 
DSS  reflects  some  of  the  personal  limitations  and  experiences  of  this 
researcher.  It  is  believed  that  what  may  help  or  hinder  a  particular  DSS 
design  project  will  vary  to  a  great  degree  from  project  to  project.  However, 
several  "universal"  variables  will  effect  most  design  projects  similarly.  This 
universal  category  includes: 

1)  Facilitators: 

a)  Regular  interaction  between  the  user  and  the  designer  for 
extended  periods  of  time;  ideally,  the  designer  should  work 
at  the  user  location  at  least  until  the  kernel  design  has  been 
decided  upon; 


Working  with  users  who  are  willing  to  try  the  adaptive 
design  process  and  if  possible  commit  themselves  for  the  life 

of  the  DSS;  their  support  will  be  needed  to  evolve  the 
storyboard  as  a  dynamic  set  of  requirements; 

Design  for  the  initial  kernel  should  be  small  and  possible  to 
implement  quickly;  the  small  implemented  kernel  will 
generate  considerable  ideas  for  what  direction  to  expand  the 
DSS; 


2)  Hindrances: 


a)  An  environment  in  which  the  underlying  decisions  are  not 
clearly  understood  or  there  exists  disagreement  on  the 
decision  process; 

b)  An  environment  in  which  the  underlying  doctrine  or  policy 

that  guides  the  decisionmaking  is  in  a  state  of  change; 

c)  Initial  unfamiliarity  of  designer  with  operational 
environment  for  which  DSS  is  being  designed; 

d)  Failure  to  find  a  DSS  champion  who  strongly  believes  in  and 
will  consistently  support  the  design  and  evolution  of  the  DSS. 


In  addition  to  these  universal  factors,  several  additional  factors 
influenced  the  retasking  DSS  design  project: 

1)  Facilitators: 

a)  User  that  has  microcomputers  and  design  software  to 
maintain  initial  storyboard  and  generate  new  ones; 

b)  User  familiarity  with  microcomputer  capabilities  to  help  in 
envisioning  what  capability  an  automated  DSS  can  provide; 

c)  Designer  having  strong  background  in  human-computer 
interface  design;  possibly  some  knowledge  in  human  factors; 


d)  Two  man  design  team;  one  to  design  with  user 
while  the  other  builds  DSS  with  inputs  from 
designer  (speculative); 

e)  Sophisticated  DSS  generator  software  (speculative); 

2)  Hindrances: 

a)  Separation  between  designer  and  user  during  critical  initial 
kernel  design  phase; 

b)  Having  to  work  with  multiple  users  at  different 
organizational  levels  all  with  different  views  about  the 
design  of  the  kernel  DSS; 

c)  No  existing  automated  system  to  support  decision;  transition 
from  an  entirely  manual  system  is  difficult  because  it  is  not 
always  clear  how  the  different  manual  tools  all  are  linked 
together; 

d)  Nonexistence  of  applicable  automated  models  to  incorporate 
into  DSS; 

e)  Inability  or  failure  to  build  the  operational  DSS  in  small 
increments  starting  shortly  after  the  kernel  is  designed; 

f)  Weak  background  of  the  designer  in  decision  theory; 

g)  Inexperience  of  the  designer  in  general  system/software 
design 


Final  Remarks 

DSSs  should  offer  tactical  decisionmakers  an  effective  means  of  assessing 
battlefield  information,  formulating  and  choosing  alternatives  and  deciding 
on  a  final  course  of  action.  With  today’s  sophisticated  tactical  data  gathering 
and  fusion  capability,  real-time  critical  decisionmaking  information  is 


available  to  the  decisionmaker  at  all  levels  of  the  tactical  battlefield.  Within 
the  ASOC,  decisionmakers  need  to  use  this  information  to  make  rapid 
decisions  on  whether  or  not  to  retask  previously  assigned  CAS  and  BAI 
missions  in  a  dynamically  changing  environment.  The  FDO  in  the  ASOC  does 
not  currently  have  a  DSS  to  accomplish  this.  The  DSS  is  needed  to  integrate 
changing  CAS  and  BAI  requests  to  use  the  best  available  weapons  at  the  time 
and  place  of  the  battlefield  commander's  choice.  It  supports  vital 
decisionmaking  for  joint  C“  operations. 

DSSs  for  tactical  decisionmaking  environments  like  the  ASOC  are  difficult 
to  design  and  build.  The  decisions  that  it  must  support  are  unstructured  and 
changing,  and  the  exact  system  requirements  are  not  completely  known. 

This  thesis  focused  on  describing  and  applying  an  appropriate  methodology 
to  translate  the  evolving  needs  of  the  ASOC  FDO  for  the  retasking  decision. 
The  methodology  used  was  adaptive  design;  it  can  be  effectively  applied 
throughout  the  life  of  the  system,  and  involves  the  critical  participation  of 
the  decisionmaker.  The  primary  activities  that  were  used  to  support  the 
adaptive  design  process  were  concept  mapping  and  storyboarding.  Concept 
mapping  was  found  to  quickly  reveal  critical  elements  of  the  retasking 
decision  process  and  was  one  tool  used  to  design  the  initial  DSS  storyboard. 
Storyboarding  was  found  to  be  an  equally  powerful  tool  for  the 
decisionmaker,  who  can  use  it  throughout  the  life  of  the  DSS  to  refine  the 
system  to  meet  his  changing  needs. 

Concept  maps  and  storyboards  for  the  retasking  DSS  were  created  and 
evolved  with  the  graphics  oriented  software  MacDraw™.  A  partial  system 
simulator  was  implemented  using  Macintosh  HyperCard™  software.  The 
HyperCard  environment  combined  with  other  Macintosh™  graphics  software, 
i.e.,  MacDraw™,  was  found  to  provide  the  flexibility  and  ease  of  use  needed 
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for  a  user  (inexperienced  in  computer  use)  to  easily  create  the  initial 
storyboard  and  them  enhance  it  over  time.  The  ability  to  link  stacks  of 
designed  representations  in  a  variety  of  user-controlled  ways  was  found  to 
be  an  invaluable  tool  for  the  user  to  build  the  system  simulator. 

The  critical  role  of  the  ASOC  decisionmakers  in  designing  the  retasking 
DSS  must  be  continued  through  the  initiatives  of  TAC/DR;  their  dynamic 
management  of  the  adaptive  design  process  is  needed  to  keep  the  retasking 
kernel  evolving.  The  needs  of  the  retasking  decisionmaker  must  continue  to 
drive  the  design  of  this  DSS. 
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The  overall  design  of  the  operating  environment  for  the  retasking  DSS  is 
modeled  after  the  desktop  operating  environment  that  Macintosh™  has 
successfully  promoted.  Several  of  the  features  of  such  an  operating 
environment  that  are  particularly  suited  to  the  retasking  environment  are  as 
follows: 

1)  Adaptable  system  for  the  user  to  selectively  call  up  functions  and 
operations  in  varying  sequences  and  at  different  times  in  the 
decision  process; 

2)  Clearly  organized  and  visible  menu  system  that  prevents  the 
decision  maker  from  getting  lost  in  a  maze  of  hierarchical  menus; 

3)  Concise  menu  driven  filing,  retrieval  and  printing  capabilities  to 
quickly  store  and  retrieve  significant  steps  or  partial  results  in  the 
decision  process; 

4)  Flexibility  to  add  or  remove  selected  functions  or  operations  as  the 
system  is  refined  without  having  to  totally  redesign  the  system; 

5)  Responsive  environment  for  both  beginners  and  experienced  users. 

Having  briefly  touched  on  these  advantages,  the  general  features  of  the 
design  for  the  kernel  DSS  will  be  described  in  the  storyboards  and 
accompanying  explanations  that  follow.  The  first  six  storyboards  depict  the 
pull-down  menus  that  are  available,  and  the  remaining  screens  provide 
some  examples  of  the  system's  designed  features  and  how  the  decisionmaker 
might  flexibly  use  them  to  reach  a  decision.  The  highlighted  feature  chart 
below  each  screen  display  shows  the  user  exactly  where  he  is  in  the  Dss 
when  using  that  display. 


TARGETS  MENU 


All  the  menus  are  placed  in  an  order  that  approximates  their  importance 
and  frequency  of  use  in  the  system;  the  first  three  menus  from  the  left  are 
at  the  top  of  this  order.  The  first  one,  the  targets  menu,  is  designed  to  allow 
the  user  to  access  different  portions  of  the  entire  targets  database. 
Immediate  and  preplanned  targets  are  listed  separately  to  allow  the  user  to 
quickly  select  and  view  minimal  critical  data  or  the  results  of  his  query. 
Under  certain  circumstances  in  a  battle,  (i.e.,  when  the  friendly  efforts  are 
shifting  from  a  defensive  battle  to  an  offensive  one)  it  may  be  necessary  to 
consider  CAS  assets  for  BAI  type  targets  because  some  of  the  CAS  targets 
may  be  replaced  by  BAI  targets  by  higher  level  planners.  The  breakout  of 
the  database  into  CAS  and  BAI  targets  allows  one  to  do  this.  If  all  targets 
need  to  be  viewed  together,  there  is  an  option  to  display  consolidated  CAS 
and  BAI  targets  through  selection  of  View  All. 

The  other  important  feature  under  this  menu  is  the  Recommend  Weapon. 
This  model  is  available  to  the  decision  maker  for  a  system  recommendation 
of  available  aircraft  and  weapon  combinations  for  the  high  priority  targets 
that  may  emerge  without  prior  warning,  or  under  other  retasking 
circumstances.  The  reason  this  option  is  under  the  targets  menu  is  that  the 
user  will  most  likely  be  viewing  targets  while  he  is  looking  for  a  system 
recommendation  on  what  assets  to  use  against  these  targets.  It  may  work 
just  as  well  under  the  weapons  menu.  In  this  case,  the  option  may  also  be 
useful  for  giving  the  user  an  estimation  of  the  effectiveness  of  a  certain 
weapon  that  is  being  considered  for  an  immediate  target.  This  model  can 
also  be  run  when  the  system  presents  an  option  window  to  perform 
weapon/target  pairing. 
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The  weapons  menu  also  offers  separate  views  of  the  CAS  and  BAI 
weapons.  Under  time  constrained  situations,  the  user  may  want  to  limit  his 
view  to  aircraft  on  short  ground  alert  or  already  airborne.  The  system 
queries  the  user  for  this  time  constraint  as  he  enters  the  system.  The  other 
view  options  in  this  menu  allow  the  user  to  quickly  select  the  type  of  view  of 
the  database  desired;  each  of  these  views  can  be  used  in  conjunction  with 
screen  representations  that  the  system  presents.  For  instance,  while  the 
user  is  viewing  the  ground  spares  available  for  reloading  on  aircraft,  he  may 
want  to  consider  the  probable  effectiveness  of  these  potential  weapons.  In 
this  case,  he  would  select  the  Effectiveness  option  on  the  menu. 

The  options  available  under  this  menu  all  relate  to  specific  information 
the  user  may  need  in  retasking  a  specific  aircraft.  The  TOT  operation  would 
figure  the  approximate  time  an  aircraft  would  arrive  at  the  desired  target 
area,  and  whether  or  not  it  would  meet  the  requested  TOT.  The  Loiter  Time 
operation  provides  an  estimate  of  the  remaining  time  that  an  aircraft  has  in 
the  air  without  refueling.  This  information  is  essential  if  the  decisionmaker 
is  to  consider  recommending  the  moving  of  aircraft  from  one  target  area  to 
another.  The  Threat  operation  provides  the  user  with  a  rough  vulnerability 
assessment,  or  an  aircraft's  probability  of  success  against  a  specific  threat 
that  may  be  encountered  under  retasking.  Part  of  the  results  of  running  this 
model  would  be  a  display  of  threat  lethality  contours  that  may  impact  a  new 
mission.  It  may  be  unwise  to  consider  certain  weapons  given  specific  threats 
in  the  target  area.  This  operation  would  alert  the  user  to  these  potential 
problems. 
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This  menu  presents  the  features  available  in  using  the  video  disk  map 
display  that  complements  the  system.  Through  this  menu,  the  user  selects 
the  type  of  map  symbology  he  needs  displayed  at  various  points  in  the 
decision  process.  He  has  the  option  of  working  with  three  different  scale 
maps  (1:50000, 1:250000,  1:500000)  of  the  same  area,  and  with  these  can 
Zoom-in  for  greater  detail  or  Zoom-out  to  view  the  bigger  picture. 
Decluttering  allows  the  user  to  hide  either  all  instances  of  a  certain  class  of 
symbols  ( i.e.,  all  low  level  transit  routes);  it  also  allows  the  hiding  of  specific 
instances  of  a  particular  symbol  if  the  user  only  needs  to  clean  up  a  certain 
portion  of  the  map  to  focus  in  on  another  aspect  of  that  area.  Plotting  and 
designing  fall  into  the  same  category,  and  allow  the  user  to  create  and 
annotate  his  own  symbols  on  the  map  display  as  needed.  For  example, 
plotting  would  allow  the  user  to  depict  a  specific  ingress  or  egress  route  on 
the  map.  Once  the  theoretical  route  is  plotted,  it  can  be  analyzed  with  the 
available  models  to  study  its  feasibility.  A  plot  showing  the  alternate  route 
of  a  retasked  aircraft  could  be  used  as  a  basis  for  a  TOT  calculation  or  the 
threat  model. 

The  Design  feature  allows  the  user  to  create  new  symbols  that  he  may 
need  for  a  particular  scenario.  It  also  allows  the  user  to  create  a  template 
that  could  be  used  (and  stored  for  future  use)  to  display  specific  user 
preferences  for  particular  situations.  For  example,  one  template  might 
contain  all  threats  that  are  potentially  lethal  to  an  A- 10  aircraft.  Another 
might  contain  a  template  of  all  targets  that  are  vulnerable  to  a  particular 
weapon;  only  those  targets  where  the  pk  of  the  weapon  exceeds  a  user 
established  value  would  be  displayed.  The  user  may  want  to  layer  these 
templates  so  that  they  appear  in  a  certain  sequence;  this  could  also  be 
accomplished  with  the  design  functions. 
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HOOKBQQK.  HELP,  and  FILE 

The  following  three  menus  provide  the  necessary  storage  and  retrieval  of 
information  and  model  results  being  generated.  The  hookbook  is  an  idea 
germane  to  adaptive  design;  by  breaking  it  out  under  a  separate  menu  it 
may  be  a  constant  reminder  to  the  user  of  the  importance  of  documenting  all 
ideas  for  system  refinements  or  changes  that  he  thinks  of  during  use  of  the 
system.  It  could  be  used  to  simply  create  narrative  files  that  contain  user 
ideas  for  system  enhancements,  as  a  type  of  notebook  organized  according  to 
subject.  Another  use  of  the  Hookbook  is  the  option  of  storing  the  sequence 
of  decision  steps  the  user  goes  through  in  making  a  decision.  This  could  be 
done  by  automatically  recording  a  specific  number  from  the  series  of  screen 
displays  that  are  presented  within  a  certain  scenario.  When  faced  with  a 
similar  decision  in  the  future,  the  user  may  want  to  recall  the  same  sequence 
of  decision  screens,  if  this  sequence  were  particularly  effective  the  first  time. 
This  option  of  recall  would  also  work  well  as  a  training  tool  for  new 
personnel  to  review  the  process  more  experienced  users  take. 

Help  provides  detailed  explanations  of  the  features  of  the  other  menus 
and  some  background  on  how  the  models  work.  The  parameters  used  in  the 
model  calculations  would  be  described,  as  well  as  any  assumptions  that  had 
been  made  in  deriving  the  models. 

The  File  menu  offers  typical  filing  and  printing  features  that  may  be 
needed  to  support  the  decision  process. 
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This  screen  allows  the  user  the  choice  of  working  exclusively  with  either 
CAS  or  B  AI  assets/targets  during  the  retasking  process.  As  mentioned 
earlier,  if  the  nature  of  the  battle  is  shifting  and  there  is  a  need  to  rerole  or 
reassign  some  of  the  CAS  assets  to  BAI  type  missions,  the  combined 
retasking  approach  would  be  desirable.  With  the  combined  feature  selected, 
the  system  would  work  with  the  CAS  and  BAI  targets  and  weapons  together. 
This  would  potentially  maximize  effective  use  of  the  full  complement  of 
available  resources  by  considering  both  types  of  weapons  for  the  two  types 
of  missions.  For  instance,  a  CAS  A- 10  loaded  with  a  Mk82  may  be  more 
efficient  and  cost  effective  against  armored  vehicles  in  the  BAI  range  than 
an  available  BAI  aircraft  loaded  with  a  maverick.  The  combined  approach 
would  allow  the  decision  maker  to  consider  these  types  of  trade-offs  while 
looking  at  the  full  range  of  available  assets.  This  capability  would  also  allow 
the  ASOC  to  respond  flexibly  to  either  CAS  or  BAI  requests;  instead  of 
referring  requests  for  aircraft  allocated  for  a  particular  mission  up  to  the 
TACC,  the  system  assists  the  decision  maker  in  meeting  the  request  at  the 
ASOC  level  by  examining  all  possible  weapons. 

The  next  portion  of  the  screen  allows  the  user  to  indicate  the  constraints 
he  is  working  under;  the  constraints  indicated  will  influence  the  results  of 
many  of  the  system  database  queries  or  models  available  to  the  user.  With 
the  time  constraint  selected,  the  system  would  only  present  those  aircraft 
options  that  would  meet  the  requested  TOT.  If  the  requested  TOT  were  not 
entered,  the  system  would  restrict  the  options  presented  to  those  that  could 
reach  the  target  within  a  pre-established  period  of  time;  a  cutoff  time  of  one 
hour  may  have  been  established  as  the  criteria.  This  established  time 
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criteria  would  naturally  be  variable,  and  could  be  easily  altererd  by  the  user. 

The  weapon  constraint  option  would  indicate  to  the  system  that  in  the 
user's  eyes,  the  available  aircraft/weapons  in  the  Corps  are  constrained. 
Under  these  circumstances,  it  is  appropiate  to  consider  aircraft  in  an  adjacent 
Corps.  If  this  option  is  not  selected,  the  system  limits  alternatives  to  both 
ground  and  airborne  alert  aircraft  within  the  Corps'  organic  assets.  Further 
along  in  the  decision  process,  the  user  has  the  option  of  further  limiting  the 
selection  to  only  ground  alert  assets  or  only  airborne  alert  assets;  he  also  has 
the  option  of  changing  the  overall  weapon  constraint  that  may  have  been 
selected  when  entering  the  system. 


This  screen  is  entered  by  selecting  the  View  Immediate  CAS  under  the 
Targets  menu,  or  by  responding  directly  to  the  system  message  to  the  user 
that  a  new  high  priority  target  has  been  entered  into  the  target  database. 
Generally,  the  decision  maker  would  be  cognizant  of  targets  that  are  being 
considererd  by  the  Army  for  attack  by  air  assets,  so  he  would  normally 
select  the  target  menu  option  to  start  the  decision  process  after  the  target 
had  been  approved  for  air  attack.  The  Targets  Window  will  open  with  the 
highest  priority  target  highlighted  for  emphasis;  priority  of  targets  is 
assigned  by  the  Army  G-3  Air  Officer.  If  aircraft  for  a  mission  have  already 
been  selected  and  scrambled,  the  Msn  Num  field  will  contain  the  mission 
number  identifier;  None  indicates  that  aircraft  have  not  yet  been  assigned. 
The  Loc  field  specifies  the  geographic  map  grid  coordinates  of  the  target 
that  corresponds  to  the  system's  map  displays.  The  TOT  field  is  the  time 
that  the  requestor  needs  the  weapon  at  the  target  location,  to  be  properly 
coordinated  with  ground  fire  and  the  momentum  of  the  friendly  battle 
initiatives.  The  Threat  field  lists  the  threats  in  the  vicinity  of  the  targets; 
additional  threats  could  be  displayed  by  selecting  Display  Threats  from  the 
ground  map  menu.  The  Cont/Callsign  field  is  the  initial  contact  point  and 
callsign  for  the  pilot  flying  the  mission  against  the  target;  the  Freq  field  is 
the  initial  contact  frequency. 

The  window  can  be  moved  to  any  comer  of  the  screen,  and  resized  to 
allow  for  the  simultaneous  display  of  other  windows.  The  scroll  bar  on  the 
right  of  the  window  with  the  up  and  down  arrows  allows  the  user  to  scroll 
through  all  targets  that  do  not  fit  in  the  window  size. 
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This  screen  displays  one  method  of  running  the  Weapon  Model  with  the 
current  highest  priority  target  as  input  to  the  model.  Two  alternate  and 
faster  ways  of  invoking  the  model  would  be  for  the  user  to  (1)  respond  to  a 
system  generated  query  of  whether  the  model  should  be  run,  or  (2)  simply 
double  clicking  the  mouse  to  start  the  model  running.  The  purpose  of 
running  the  model  is  for  the  system  to  quickly  scan  the  available  weapons  in 
the  database  and  filter  out  any  of  those  that  would  be  inappropiate  to 
consider  for  the  target  in  question;  the  results  of  the  model  are  a  listing  of 
the  recommended  optimal  weapons,  based  on  the  probability  data  available 
in  the  Joint  Munitions  Effectiveness  Manuals  (JMEM).  The  minimal  weather 
requirements  to  achieve  a  desired  probability  of  kill  (pK)  are  also  included 
because  they  are  a  significant  factor  in  the  success  of  the  mission. 
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MODEL 


To  run  the  weapon  model  ( Recommend  Weapon),  the  user  is  required  to 
specify  certain  variables  in  the  model.  The  first  variable  is  the  category  of 
alert  aircraft  to  be  considered;  the  three  categories  being  (1)  airborne  alert, 
(2)  ground  alert,  or  (3)  both  airborne  and  ground  alert.  Through  selection  of 
this  variable,  the  user  is  indicating  the  urgency  of  the  mission,  or  how 
quickly  a  weapon  must  be  at  the  target  area.  Even  though  there  may  be  no 
aircraft  on  airborne  alert  to  be  used  as  needed  during  the  battle,  other 
aircraft  that  may  already  have  been  assigned  a  mission  but  have  not  yet 
reached  their  final  contact  point  may  be  considered  as  viable  alternatives. 
Once  aircraft  have  reached  their  final  control  or  orbiting  point  and  are 
talking  to  their  contact,  it  is  generally  too  late  and  too  complicated  to  retask 
them,  and  their  fuel  level  too  low  to  consider  moving  them  to  another  target 
area. 

Besides  selecting  the  type  of  alert  aircraft  to  be  considererd,  the  user 
must  indicate  a  desired  pK  for  the  mission.  If  no  pK  is  indicated,  the  system 
default  is  to  select  the  three  weapons  with  the  highest  pKs,  regardless  of 
what  the  actual  pK  values  are.  The  advantage  of  this  limited  list  of 
alternatives  is  that  under  severe  time  constraints,  the  user  would  not  be 
inundated  with  a  long  list  of  weapons  to  consider. 
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The  results  of  the  weapon  model  are  displayed  here.  The  format  used  is 
a  window  which  can  be  altered  in  size  and  displayed  with  other  relevant 
windows,  as  the  sample  screen  shows.  The  user  has  the  capability  to  scroll 
through  the  resulting  aircraft/weapons  if  they  do  not  all  fit  in  the  window. 

The  Type  field  describes  the  type  of  aircraft  available  in  the  database 
that  would  be  suited  to  attack  of  the  highlighted  target  in  the  targets 
window.  The  OrdnanceINo  field  contains  the  type  and  quantity  ordnance 
currently  loaded  on  the  aircraft.  The  Fuzing  field  indicates  the  type  of 
fuzing,  which  is  an  important  factor  in  the  pK  of  the  weapon.  The  pK  is 
indicated  to  give  the  user  a  general  criteria  for  ranking  the  aircraft/weapon 
alternatives.  It  is  important  to  note  that  the  alternatives  presented  all  meet 
the  requested  TOT  within  a  certain  degree  of  error.  For  the  sake  of  the 
example  given,  the  degree  of  error  is  fifteen  minutes.  The  last  two  fields, 
Ceiling  and  Visibility  represent  the  minimal  weather  required  to  achieve 
the  pK  provided.  One  of  the  requirements  of  the  model  is  to  filter  out  those 
aircraft/weapon  alternatives  that  would  not  be  appropiate  under  current 
weather  conditions  in  the  target  area. 

With  the  alternatives  presented,  the  user  has  several  options  he  may 
choose.  The  most  logical  may  be  to  select  an  aircraft/weapon  and  query  the 
system  for  more  detailed  information  for  planning  the  mission. 
Alternatively,  he  may  want  to  view  the  target  area  on  the  ground  map  with 
projected  weather  overlays.  If  a  change  in  the  target  area  weather  is 
anticipated  near  the  requested  TOT,  it  may  be  advantageous  to  run  the 
model  with  the  projected  weather  forecast,  to  see  what  new  alternatives  are 
produced. 


Targets  Weapons  Ground  Map  Hookbook  Help  File 


CAS  Targets  Window 


Man  Num 

Priority 

Type  Loc 

Iffll 

Threat 

Cont/Callsan 

Frea 

54341 

2 

Tanks 

1200 

ZSU-23 

FAC/Sniper 

237.4 

None 

1 

Armored 

Carrier 

1215 

Light 

Arms 

TACP'Snake 

234.7 

None  2 

Tanks 

1230 

SAM 

CRC/Angel 

256.8 

Recommended  Aircraft/Weapons 


'Targets/  /Weapon0-^  /Ground 


Zoom 


gclutler 


Plol 


Hookbook 


ffectiveness 


Ground  Soares 


Other  Cor 


i 


This  screen  displays  the  sequence  of  actions  in  selecting  an 
aircraft/weapon  and  displaying  detailed  information  on  the  different 
alternatives.  The  user  can  highlight  the  desired  aircraft/weapon  with  the 
mouse;  a  double  click  of  the  mouse  will  bring  up  a  window  with  detailed 
data  on  the  single  alternative  selected.  However,  if  the  choice  of 
aircraft/weapons  is  not  clear-cut  at  this  point  in  the  decision  process,  the 
user  may  decide  to  select  the  Selection  option  from  the  Weapons  menu. 
Choosing  this  route  will  display  further  information  on  all  of  the 
recommended  aircraft/weapons,  so  an  examination  of  the  trade-offs  of  using 
each  of  the  different  alternatives  can  be  made. 
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Since  the  Selection  option  was  chosen  on  the  previous  screen,  all  three  of 
the  aircraft/weapon  alternatives  are  listed  according  to  the  ranking  of  their 
pK  values.  The  decision  maker  may  need  to  review  this  data  to  further 
differentate  between  the  alternatives  presented.  For  example,  the  pKs  given 
for  the  three  alternatives  are  fairly  close  in  value.  Clearly,  their  pKs  will  not 
be  the  deciding  factor.  The  target  in  question  may  be  extremely  mobile  and 
there  may  be  little  allowable  variation  from  the  requested  TOT.  In  this  case, 
the  alert  status  of  the  aircraft  and  actual  TOT  calculation  may  be  necessary 
information  for  the  decision. 

Within  the  window  displayed,  the  Base  field  indicates  the  home  base  of 
the  aircraft  or  the  base  it  is  currently  operating  from.  This  information  is 
relevant  for  the  user  to  know  where  he  is  selecting  assets  from,  so  that  an 
imbalance  in  aircraft  distribution  is  not  unknowingly  created.  The  TOT  field 
is  the  result  of  another  background  system  model  that  automatically 
calculates  the  actual  TOT  for  each  of  the  alternative  aircraft.  This  field  is 
important  because  the  weapon  with  the  highest  pK  value  may  be  the  last  to 
be  able  to  reach  the  target  area.  An  airborne  aircraft  that  is  currently  under 
control  of  the  Control  and  Reporting  Center  (CRC)  may  be  able  to  reach  the 
target  area  nearest  the  requested  TOT.  The  Alert  field  shows  the  time  for 
the  aircraft  to  take-off  or  indicates  airborne  if  the  aircraft  is  orbiting  or 
headed  to  a  previously  assigned  target  area.  The  Control  field  shows  the 
agency  currently  controlling  the  aircraft,  if  the  aircraft  is  already  airborne. 
The  Mission  Number  field  provides  further  confirmation  of  whether  the 
aircraft  has  been  previously  assigned  to  a  mission.  With  this  information, 
the  decision  maker  may  be  fully  armed  to  proceed  with  final  selection. 
However,  he  may  want  to  review  the  alternatives  in  relation  to  other 
qraphical  data  on  the  ground  map  display. 
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With  the  target  selected  and  several  alternative  aircraft/weapons 
recommended,  it  may  be  necessary  for  the  decisionmaker  to  move  to  the 
Ground  Map  display  to  view  the  same  data  in  its  graphical  relationship  and 
in  relation  to  the  bigger  picture  of  the  battle. 

This  is  achieved  by  selecting  those  items  to  be  displayed  on  the  map  from 
the  Ground  Map  menu.  The  highest  priority  Targets  at  the  current  time 
may  be  displayed  to  show  the  (distance  and  terrain)  relationship  between 
those  targets  that  may  already  have  aircraft  assigned  and  those  that  still  do 
not  have  aircraft  assigned.  By  viewing  these  targets  in  relation  to  one 
another  and  the  big  picture,  it  may  quickly  become  apparent  how  each  fit 
into  the  overall  friendly  initiatives,  and  perhaps  which  aircraft/weapon 
would  be  better  suited  to  the  particular  target  environment.  By  displaying 
Threats  and  corresponding  lethality  contours,  the  specific  areas  of 
vulnerability  for  aircraft  would  become  vivid.  It  may  be  extremely  difficult 
to  get  an  aircraft  from  its  current  location  to  an  alternate  target  with  the 
threats  in  between.  This  would  not  be  evident  without  viewing  this  selected 
graphical  data.  In  highly  congested  airspace,  in  which  low-level  transit 
routes  are  required  to  move  the  aircraft  to  the  battle  area,  it  may  become 
important  to  view  these  routes  and  the  current  location  of  the  aircraft  that 
would  be  required  to  fly  the  route  if  retasked.  It  may  also  be  important  to 
view  aircraft  orbit  areas  to  determine  the  overall  utility  of  retasking  an 
aircraft  already  in  one  orbit  area  for  another  orbit  or  for  a  different  target 
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This  is  another  system  tool  or  model  to  use  in  selecting  an  aircraft  from 
different  alternatives  for  retasking.  It  is  particularly  important  to  evaluate 
the  feasibility  of  retasking  airborne  aircraft  for  an  alternate  mission.  This 
model  requires  real  time  information  on  an  aircraft’s  fuel  level;  this 
information  is  currently  not  available  without  talking  directly  to  the  pilot. 
However,  with  several  of  the  future  tactical  information  distribution 
systems,  this  real  time  data  could  very  well  become  a  reality.  To  use  this 
model,  the  user  must  select  a  particular  aircraft/weapon  to  be  used  against 
the  highlighted  target.  Although  the  target  window  is  hidden  on  this  sample 
display,  the  target  selected  is  still  the  original  one  displayed  in  the  targets 
window.  For  an  aircraft  that  will  be  moved  to  an  alternate  target  area  under 
retasking,  the  model  will  calculate  the  fuel  needed  to  fly  to  the  new  target 
area  and  then  figure  loiter  time  from  the  remaining  fuel.  Although  an 
aircraft  may  be  able  to  reach  an  alternate  target,  it  may  be  unsuitable  for 
use  because  of  a  small  amount  of  remaining  loiter  time. 

It  is  generally  believed  that  minimal,  if  any,  aerial  refueling  capability 
will  be  available  for  CAS  or  B  AI  missions.  With  this  limitation,  the  loiter 
time  model  could  currently  calculate  remaining  loiter  time  if  an  accurate 
aircraft  take-off  time  was  known  for  each  mission. 
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The  results  of  the  loiter  time  model  are  displayed  on  this  screen.  The 
Mission  field  indicates  the  mission  number  that  has  previously  been 
assigned  to  the  aircraft  that  has  already  been  tasked.  If  the  loiter  model 
were  used  with  an  untasked  aircraft,  the  field  would  read  none  assigned. 

The  Type  field  contains  the  type  and  quantity  of  aircraft  that  were  used  as 
input  to  the  loiter  time  model.  If  there  are  multiple  aircraft  with  different 
loiter  times,  the  results  will  report  the  corresponding  loiter  time  for  each 
aircraft  separately.  The  Target  field  holds  the  target  that  has  been  selected 
in  the  target  window,  even  if  the  aircraft  has  already  been  assigned  to  a 
different  target.  In  a  case  like  this,  the  model  will  subtract  the  time  needed 
to  get  to  the  new  target  from  the  loiter  time  so  that  the  user  will  not  have  to 
make  this  calculation.  The  Loiter  Time  field  contains  the  amount  of  time  in 
minutes  that  the  aircraft  can  remain  over  the  target  area  before  it  must 
begin  its  egress  to  a  recovery  base.  The  last  field.  Holding  Area  ,  is  pertinent 
for  CAS  missions.  These  holding  areas  are  temporary  orbit  areas  where  the 
aircraft  may  wait  for  a  short  period  of  time  before  ingress  to  the  target  area 
and  their  final  contact  point  in  the  battle  area.  Holding  areas  may  be 
another  piece  of  data  that  are  particularly  suited  for  graphical 
representation  on  the  map  display.  It  may  be  beneficial  for  a  decision 
maker  considering  retasking  to  see  an  aircraft's  current  holding  area  in 
relation  to  a  new  target  area  and  its  corresponding  new  holding  area. 
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This  screen  representation  does  not  follow  in  sequence  from  the 
preceeding  ones.  Instead,  it  presents  the  questions  that  the  system  would 
ask  the  userin  order  to  run  the  weapon  model  under  a  weapon  constrained 
scenario.  When  the  user  earlier  entered  the  system,  he  was  asked  to 
indicate  if  there  was  a  weapon  constraint  with  the  current  mission  retasking 
or  replanning.  If  no  weapon  constraint  is  indicated  at  this  initial  point,  the 
system  will  only  consider  weapons  that  are  organic  to  the  Corps  associated 
with  the  ASOC  doing  the  retasking.  However,  if  the  weapon  constaint  is 
selected,  the  system  will  consider  aircraft/weapons  from  adjacent  Corps  that 
would  be  appropiate  for  possible  retasking. 

This  screen  display  shows  that  the  system  repeats  the  weapon  constraint 
question,  in  case  the  situation  has  changed  since  the  retasking  system  was 
entered.  The  user  is  also  asked  to  select  whether  airborne  alert,  ground 
alert,  or  a  combination  of  both  should  be  considered  in  running  the  weapon 
model.  The  third  selection  that  the  user  must  make  is  whether  both  CAS  and 
B  AI  type  aircraft/weapons  should  be  considered  in  running  the  weapons 
model.  Under  a  scenario  in  which  the  requirement  for  CAS  missions  is 
suddenly  and  dramatically  increased,  it  may  be  necessary  to  consider  BAI 
assets  as  well  as  CAS  for  possible  retasking. 


T  argets 


Weapons  Ground  Map  Hookbook  Help  File 


View  CAS 
Immediate 
Current 
Historical 
Preplanned 
Current 
Historical 


View  BAI 
Immediate 
Current 
Historical 
Preplanned 
Current 
Historical 


CAS  Targets  Window 


Weapon 


Type  Loc 

Tank* 

mi 

1200 

Threat 

ZSU-23 

Cont/Callsan 

FAC/Snlpar 

Frea 

237.4 

A  r  mored 

Carrier 

1215 

Light 

Arms 

TACP  Snake 

234.7 

Tanka 

1230 

SAM 

CRC/Angal 

2S6.8 

View  All 


Do  you  wish  to  consider  both  airborne  and  ground  assets? 
Select:  Air  Only  Q  Grnd  Only  Both 

Select:  Weapon  Constrained  Unconstrained  Q 


«  * 

/  Main  Menu; 

/• 

/  Desktop  / 

fmirwA 


Hookbook 


mmi 


lEmn! 


iKHBinii 


[ESIESIHSHb] 


EHecliveness 
Ground  Spares 
I  Other  Corps 


VI*«3 


■  *  i«.  ji.  ji.  i*.  >b.  it.  ib.  i>,  tb.  iV  AL  i»-  iU  i<»  iL  iL  A*; 


RIORITY  TARGET  WINDOW 


This  window  is  presented  to  the  user  automatically  without  any  input 
from  him.  The  window  alerts  the  user  to  the  recent  addition  of  another  high 
priority  target  to  the  database's  list  of  targets.  The  user  can  quickly  see  the 
designated  Army  priority  and  requested  TOT  of  the  new  target  in  this 
abbreviated  display.  He  has  the  option  of  continuing  with  his  current 
mission  retasking  or  can  select  new  ,  which  presents  the  full  targets  window 
with  the  corresponding  information  on  the  new  target.  If  the  user  selects  to 
continue  his  current  planning,  the  window  will  disappear;  however,  it 
reappears  in  a  short  time  period  if  the  system  detects  that  the  target  has  not 
been  selected  for  planning  a  mission  against  it.  This  feature  prevents  the 
decision  maker  from  getting  so  engrossed  in  a  current  mission  plan  that  he 
lets  incoming  high  priority  requests  pile  up  unattended. 
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This  display  would  appear  when  the  user  selected  the  Ground  Spares 
option  from  the  Weapons  menu.  Although  the  likelihood  of  examining 
ground  spares  for  CAS  missions  is  small,  it  may  be  necessary  when  time 
constraints  are  not  a  major  factor  and  the  target  requires  a  unique 
aircraft/weapon  configuration.  A  particular  target  must  be  highlighted  for 
the  system  to  search  the  database  and  present  the  available  ordnance  that 
could  be  reloaded  on  the  aircraft.  If  a  recommended  aircraft  has  already 
been  selected  in  the  Recommended  Aircraft/Weapon  Window,  then  the 
system  will  ask  whether  the  user  wishes  to  view  all  spare  ordnance 
appropriate  against  the  target,  or  only  that  spare  ordnance  that  is  available 
to  be  used  with  the  selected  aircraft.  The  user  may  have  already  decided 
that  a  particular  aircraft  must  be  used,  and  only  wants  to  see  whether  other 
ordnance  is  available  to  be  loaded  on  it.  On  the  other  hand,  the  choice  of  a 
particular  aircraft  may  be  secondary;  the  objective  might  be  to  find  the  best 
ordnance  available  to  be  loaded  on  any  available  aircraft  of  a  certain  type. 

In  other  words,  the  type  of  aircraft/weapon  combination  may  be  critical,  but 
the  location  of  the  aircraft  and  timing  of  the  aircraft  over  the  target  may  not 
be  as  critical  a  factor. 
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This  window  displays  the  results  of  the  Ground  Spares  menu  selection 
that  was  previously  made.  The  Target  field  repeats  the  type  of  target  that 
was  selected  in  the  Targets  Window.  The  Base  field  shows  where  the 
indicated  weapons  or  ordnance  are  located.  The  last  six  subfields  of  the 
Weapons  field  are  the  types  of  weapons  that  are  effective  against  the  target. 
An  X  checked  under  a  certain  column  indicates  that  at  least  one  load  of 
spares  of  that  type  of  weapon  is  available  at  that  base.  Only  spare  ordnance 
that  can  be  used  on  the  available  CAS  or  B  AI  aircraft  is  displayed.  If  there 
remains  spare  ordnance  at  a  base  where  there  are  no  longer  any  available 
aircraft,  the  ordnance  will  be  displayed.  This  will  allow  the  user  to  corn  ider 
the  possibility  of  reloading  aircraft  from  other  locations  with  the  spare 
ordnance  at  a  certain  base,  or  recommending  recovery  of  aircraft  at  bases 
where  the  ordnanace  level  is  most  favorable.  The  spare  ordnance  window 
would  also  assist  the  decision  maker  in  considering  the  possible  reroling  of 
CAS-configured  aircraft  to  BAI  missions,  or  vice  versa. 
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Many  of  the  ideas  for  enhancing  the  retasking  DSS  were  triggered  by  > 

« 

working  on  the  initial  storyboard  design;  others  were  contributed  by 
decisionmakers  and  thesis  advisors  commenting  on  the  requirements  for  the 

i 

initial  design.  The  power  of  the  hookbook  is  that  the  decisionmaker  is  not  | 

i 

constrained  by  technology,  or  other  external  influences  when  refining  and 
documenting  his  needs  through  the  hookbook  entries.  Some  method  for  the 
user  to  maintain  a  hookbook,  preferably  automated  as  described  in  Chapter 
V,  should  be  supported  as  soon  as  possible.  Many  of  the  detailed  DSS 
display  and  operation  refinements  can  be  documented  through  this 
technique.  On  the  other  hand,  the  hookbook  ideas  that  are  presented  below 
are  more  general  in  nature,  and  would  require  considerable  more 
preliminary  design  and  implementation  effort.  They  have  been  prioritized 
by  this  researcher  based  on  criteria  for  more  carefully  integrating  the 
spectrum  of  battlefield  initiatives  that  are  often  linked  to  the  ASOC  retasking 
decisions: 

Commander's  Priorities.  The  DSS  should  support  retasking  and  rapid 
replanning  based  on  a  prioritization  of  missions  that  correspond  closely  with 
the  Commander's  guidance  and  overall  priority  of  targets  for  a  particular 
timeframe.  The  requirement  here  involves  the  FDO  being  able  to  see  the 
"bigger  picture"  through  use  of  the  retasking  DSS.  The  system  scanning  of 
the  database  and  later  the  knowledge-base  must  be  able  to  incorporate  the 
Commander's  priorities  into  the  criteria  it  uses.  The  options  presented  to  the 
decisionmaker  must  meet  this  criteria.  A  knowledge-based  system 


evaluation  of  the  final  option  that  the  decisionmaker  choses  could  also  check 
for  alignment  with  the  overall  priorities.  It  is  believed  that  use  of  the 
geographic  display  would  be  very  important  for  support  in  this  area. 


Corps  1q  Corps  Integration.  The  DSS  should  support  the  integrating  of 
potential  targets  that  may  be  entering  Corps  area  from  another  Corps,  or 
exiting  the  Corps  area  to  another  Corps.  This  requirement  also  involves 
presenting  the  "bigger  picture"  to  the  decisionmaker  in  a  manner  that  is  not 
overwhelming  for  him.  Much  of  the  information  for  this  enhancement  will 
be  dependent  on  the  availability  and  reliability  of  intelligence  sensors.  The 
DSS  must  incorporate  this  information  into  its  knowledge-base,  and  use  it  as 
a  filter  when  presenting  views  of  the  data  and  viable  options  to  the 
decisionmaker. 

Integrate  With  Fire  and  Manuever.  The  DSS  should  be  able  to  support 
retasking  and  rapid  replanning  through  detailed  coordination  and  integration 
with  the  fire  and  manuever  plans  of  friendly  surface  forces.  Satisfying  this 
requirement  depends  on  interfacing  the  retasking  DSS  with  the  Army 
integrated  Sigma  Star  system;  the  system  that  supposedly  will  support 

9 

decisionmaking  and  C  with  information  from  the  five  major  information 
sources  on  the  battlefield.  It  also  depends  on  the  ability  of  the  DSS’s 
knowledge  base  to  incorporate  the  surface  forces'  plans  and  use  them  as 
criteria  in  presenting  options  for  the  ASOC  decisionmaker.  During  the  crisis 
retasking  decisions,  the  FDO  must  be  able  to  quickly  assess  the  potential  role 
of  the  surface  forces  in  the  new  plan  that  is  being  drawn  up.  It  is  important 
to  assess  the  capabilities  and  support  that  the  surface  forces  already  in  place 
have;  sending  an  aircraft  in  may  be  extremely  wasteful,  and  worst  yet,  it 
could  place  the  crew  in  a  high  threat  environment  unnecessarily. 


Forecasting.  The  DSS  should  be  able  to  support  a  certain  degree  of 
forecasting  of  both  anticipated  CAS  and  BAI  mission  requirements  in  a 
certain  scenario;  it  should  also  offer  a  plan  for  the  general  mission  tasking 
over  a  period  of  time.  Not  all  of  the  FDO's  retasking  will  be  immediate  in 
nature.  Occasionally,  there  will  be  time,  because  of  a  longer  range  target  or 
special  intelligence  information,  to  evaluate  the  retasking  with  a  fully 
integrated  weapon  database.  As  weapon  delivery  platforms  become  more 
multi-role  capable,  it  is  essential  that  they  be  closely  integrated  in  the  DSS. 
The  DSS  must  also  possess  the  capability  to  predict  where  and  how  the 
weapons  can  best  be  used;  in  an  extremely  weapon  constrained  scenario  it 
will  be  essential  for  the  FDO  to  have  some  reliable  tools  through  the  DSS  to 
predict  the  most  effective  battlefield  points  to  use  the  limited  weapons  on. 

Airborne  Operations.  The  DSS  should  be  able  to  support  specialized 
retasking  and  immediate  planning  in  support  of  joint  airborne  operations; 
the  supporting  ASOC  in  this  case  may  be  airborne.  The  advantage  of  the 
ASOC  in  an  airborne  position  would  be  access  to  real-time  battlefield 
information  and  positive  and  direct  C2.  The  ability  of  the  DSS  to  rapidly 
present  options  to  the  FDO  in  a  quickly  changing  scenario  would  be  crucial. 
In  this  role,  the  DSS  may  require  an  air  situation  display  to  support  the 
direct  C2. 

Integrate  With  SQF.  The  DSS  should  be  able  to  support  the  consideration 
of  Special  Operating  Forces  (SOF)  that  may  be  available  to  contribute  to  a 
retasked  mission.  This  capability  meshes  closely  with  the  other  DSS 
capabilities  that  use  a  fully  integrated  data/knowledge-base  to  present 
options  to  the  FDO.  In  certain  scenarios,  or  certain  battlefield  areas,  the 


combined  efforts  of  CAS/BAI  assets  and  SOF  may  be  required  to  achieve  the 
desired  results.  The  DSS  should  be  able  to  assess  when  this  situation  exists 
and  tailor  the  presentation  of  information  and  options  for  the  FDO. 

These  prioritized  hookbook  ideas  should  be  further  examined  and  refined 
by  the  TAC  referee  and  the  ASOC  decisionmakers  as  the  retasking  DSS 
evolves. 
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